AI implementation, anywhere in Australia.

Kaima › Services

Does not being in Sydney change anything?

Two things, and neither is the thing people expect. It does not change who does the work, and it does not change what gets built. What it changes is the rhythm: how discovery happens, and how often you see something.

Almost all of this work is done remotely regardless of where the client is. Reading how your systems fit together, building against them and reviewing what comes out does not require anyone to be in the room, and pretending otherwise would just add travel to your invoice.

What genuinely differs

• Discovery is scheduled rather than opportunistic. Locally, a lot gets picked up by being present. Remotely it has to be deliberate, which means longer structured sessions and more of them at the start.
• You see working software earlier and more often. When you cannot drop in, the substitute is showing you the thing itself on a short cycle instead of describing progress.
• Decisions get written down more. A hallway conversation is not available, so the record has to carry the weight instead, which is better practice anyway and is what we do locally too.

What does not differ

The same two founders, on your engagement, for its whole length. The same review before anything ships. The same assessment first, so nobody quotes you before there is a written view of whether the work is worth doing.

There is no regional tier of this business and no junior team that handles the clients further away. If that were the arrangement we would say so, because you would find out.

What we changed after distance cost us something

Worth saying what it cost before saying what we do about it, because the second only means anything with the first attached.

A written reply to a colleague sat finished in a file for two days while he waited for it. Nothing was refused and nothing was disputed; the answer simply had not been sent, and from the other end a silence and a refusal look identical. On another piece of work a build ran for weeks with nobody able to see it running, so the first anyone saw of it was a finished thing rather than a developing one. And once we did the same job twice, because two people fixed the same problem in parallel rather than waiting.

None of those is a technology failure. They are all the same failure: work that was real but not visible.

So four things changed, and they are the ones you would see

• Work is opened for review on its first day, before it is any good, so it can be watched while it happens instead of arriving finished and unarguable.
• Handover notes live with the work, not in a chat window somebody has to scroll back through.
• Questions are batched into one weekly list, each with a recommended answer and a date by which it decides itself, so nobody is blocked waiting for a reply across a timezone.
• A check at the start of every working session reports anything that has been worked on and not made visible.

What the distance buys, in return, is that the work continues while you are asleep. That is genuinely useful and it is worth less than it sounds if you cannot see what happened overnight, which is why the four items above exist.

What actually delayed the remote build, and it was not the distance

Everything above is what we got wrong. This is the other half, and it is the more useful one, because it is the half you can do something about before anyone starts.

One engagement ran entirely by email: about a hundred and fifty messages over six weeks. Discovery went out on the second day as a short brief, six questions plus a request for the approved content, a sitemap, and the name of the person who signs off. The substantive answer came back three weeks later. The person who signs off was not named for five.

In between, instructions arrived from four people and contradicted each other, and the content the chief executive believed was missing turned out to be sitting with his own team, waiting for his review. Nobody was withholding anything. It still cost weeks.

None of that is about distance. A remote build is not slowed by the kilometres. It is slowed by a decision with nobody’s name on it, and locally that gets solved by walking down a corridor. A corridor is precisely what is missing.

So three things get asked for on day one

• One name against sign-off, written down. Not a committee, and not the most senior person by default: the one whose approval actually ends an argument.
• One route in. Four people giving instructions is not four times the information. It is four versions of it, and the only thing that guarantees is building the wrong one quickly.
• The content and the access before the build, not during it. This is the one clients underestimate, every time, and it is the one that decides whether week three is a build week or a waiting week.

Where distance genuinely is a problem

Work that depends on watching people do their jobs is harder at a distance. If the process you want changed is one nobody can describe accurately, where the real version differs from the written version and only observation would reveal it, then remote discovery will take longer and cost more, and it is fair to know that before starting, not after.

There is no list of cities we serve, because it would be marketing rather than information. The question that matters is what the work needs, not where you are.