We build what we recommend.

A consultancy that writes the software. We work out what the problem actually is, then the same people build the thing that solves it — and we run our own products the same way.

AdvisoryDesign and deliveryOwn products

01 / What we do

Two halves of one job

Advice that is never built is a document. Software built without the advice is a guess. Neither half is worth much on its own, and they are usually sold separately.

We advise

Discovery, requirements and architecture. Most of the value is in working out what the problem actually is, which is rarely what the brief says it is — and in writing down what is still unknown as plainly as what is settled.

We build

The people who wrote the recommendation write the code. There is no hand-off to a delivery team that was not in the room, and no second discovery at the stage where it costs the most to find something out.

Why it matters

Nobody to hand the risk to.

One team · advice through to production

When advice and delivery are bought from different suppliers, the split is comfortable for both of them. If the estimate turns out to be wrong, the advice was sound and the build was at fault, or the other way around, and the client pays for the argument.

We do not have that exit. If the architecture we recommended turns out to be the wrong one, we are the people who have to make it work — which concentrates the mind at the only stage where changing it is still cheap.

02 / What we take on

Described by what it produces

Discovery and requirements

The problem written down in a form that can be built from and argued with: what is decided, what is assumed, and the questions that change the answer depending on how they are answered.

Product design and build

Web applications end to end — design system, front end, data, deployment, and the operational half nobody demonstrates.

Data, mapping and routing

Distance, location and coverage worked out on real road networks rather than straight lines, with the accuracy measured and stated rather than assumed.

AI where it earns its place

A language model turns a sentence into parameters. Plain code does the arithmetic. Anything that produces a number someone will act on stays deterministic and testable, because a figure that cannot be traced back is worse than no figure at all.

Tools your own team can maintain

Rates, catalogues and rules kept in a spreadsheet the people closest to them already know how to use. Changing a price should not require a developer, a release and a queue.

Running it afterwards

Hosting, support and the unglamorous half, itemised line by line so it can be judged on its merits rather than carried as an unexplained percentage.

Automation

The steps between systems — the re-keying, the chasing, the copying from one screen into another that appears in nobody's job description. Worth doing only where the process is already understood: automating one nobody has examined makes it fail faster and less visibly.

A firm that only ever spends other people’s money never finds out which of its opinions are expensive.

Which is why we run our own

03 / Our own products

We are our own most demanding client

Alongside client work we build and run software we own, in the same markets and on the same stack. It is where an approach gets tested before it is recommended to anybody else.

Why that is on this page

Running our own products means the trade-offs we recommend are ones we have already paid for ourselves, on our own time and our own money.

04 / Getting started

Start with the problem, not the brief

If you can describe what is going wrong, that is enough to begin. The first conversation is free, and more often than not it changes the brief.

hello@onegai.com.au