The prototype is the easy part.

Kaima

What you already proved, and what it did not tell you

If you have sat down with Claude or Codex and built something that worked, you proved something real. It is not a toy result and it is not beginner's luck. The thing you built genuinely does the thing.

What it did not tell you is how long the rest takes. You proved the capability on a laptop, alone, against data you were allowed to break, with nobody depending on the answer. Every one of those four conditions changes the moment the same idea has to run inside the business.

So the experiment sets your expectation of difficulty in the wrong place, and it does it in both directions at once. The build is faster than you think. The implementation is harder. People who have never touched the tools get this wrong by guessing. People who have touched them get it wrong for a better reason: they are extrapolating from real evidence that happens not to cover the expensive part.

The five things that change when it leaves your laptop

None of these is exotic. They are the ordinary conditions of software that other people depend on, and they are the reason the same idea costs what it costs once it is real.

1. Somebody else's data is now in it

On your laptop you were the only person who could be harmed by a mistake. In the business, the material going through the system belongs to clients who did not agree to an experiment. That changes where the data may sit, who may see it, what gets logged, and what happens to it when a staff member leaves.

2. It has to be right when nobody is watching

A demo is supervised by definition. You were sitting there. Production runs at 6am on a Sunday with no one at the keyboard. That is a different engineering problem, and it is mostly about what the system does when it is not confident rather than when it is.

3. It connects to systems that already exist

The prototype had one input, which you pasted in. The real version reads from the software you already run, and those systems were not built to be read from. Most of the cost of an integration is not the AI. It is the shape of the data on the other side of it.

4. People have to use it, and they get a vote

A tool nobody adopts is an expense, not an asset. Adoption is not a training session at the end; it is a design constraint from the start, and it is the single most common reason a technically correct build produces nothing.

5. Somebody has to be able to change it in a year

Including someone who is not you and was not there. That means the decisions get written down, not just the code, which is the difference between a system a business owns and a system it is renting from whoever built it.

You are right to ask about client data first

One of the clearest enquiries we have had put it like this: “I want to implement AI, but I want to do it properly, protect our client data and make sure everything is compliant and safe.” That arrived unprompted, in the opening message, before any discussion of what to build.

It is the right instinct, and it is not an obstacle to the work. It is the work. Where the data lives, which systems may reach it, what the model is allowed to retain, who can see an output and what is recorded when they do. These get decided before anything is built, because retrofitting them means building it twice.

What we do about each one, on our own builds

We can show this rather than assert it, because the discipline runs on our own work first. There is no client involved and nothing to get permission for.

• Every change is reviewed against a written standard before it ships, by a reviewer who is not the person who wrote it.
• Architecture decisions are recorded with their reasoning, including the ones we later reversed, and why.
• Security review is a gate, not a step. Anything touching credentials, authentication or somebody else's data does not proceed on a promise to look at it afterwards.
• Deployment authority sits with one role and is not delegable, so nothing reaches production because everyone assumed somebody else had checked.
• The checks are automated where a human would drift. A rule nobody measures decays, and it decays silently, which is worse than not having it, because it still looks live.

This website is built the same way. The interviews behind it are kept, the review decisions are written down, and the parts we could not yet write are marked as unwritten, not filled in. You are welcome to ask to see how any of that works.

What this makes the work cost, and why

Understanding why production is hard is most of the way to understanding the price. The build is rarely the expensive part. The expensive parts are the integration surface (how many systems it has to touch), the state of the data on the other side, and how much of your own knowledge has to go into it.

We publish what moves that number rather than a price list, because the answer to “what does this cost” is that it depends on which of three quite different things you want.