SAT FUSIONSoftware architecture
All services

The prototype grew into a product

The product holds live users, not a demo.

The situation

A prototype built with AI has become a product, and it has live users.

It did what it was built for: it showed the idea quickly and cheaply. Then the unplanned thing happened — people started using it. Now it has data that cannot be lost, people who call when it is down, and promises somebody made.

What happens

The second half gets built. An application solves two categories of task: the user's and the product owner's. Prototypes do the first and almost never the second — which is not carelessness but their purpose. The product owner arrives later, together with money, reporting, access rights, incident reviews and the question of who did this and when.

What carries the users is separated from what was scaffolding. The speed of assembly was bought by doing much of it once-only. Some of that is cheaper to remove than to build up.

The behaviour is recorded while it is still known. What the system does today — before opinions appear about what it should do. Only what has been written down can be removed safely.

The price of production is named. Live users mean recovery after failure, data that survives, updates without downtime, and a person who answers for it at night. None of those requirements follows from the prototype working.

What you get

A product that holds live users rather than a demo. And an honest bill: what is worth finishing, what is cheaper to remove, and what the first year will cost.

A machine will read and write volume a human never would. Reading and typing got cheaper; judgement about what was read did not — and judgement is what is bought here.

This is not an argument about AI. A prototype built with it is a normal beginning, and what is worth discussing is not where the code came from but what it lacks for the second half of the tasks.

How it went

A vending system written end to end with AI, and then rewritten with AI. I did not read the code — only what flashed past in the console: the machine gathered the material and proposed the decisions, and the steering happened at the level of architecture.

It was legacy from its first month, though the project had only just started. The documentation contradicted itself; tools stood where they did not belong. Age has nothing to do with it — what makes something legacy is that nobody knows any more why it is the way it is.

What this is not

Rewriting from scratch by default. A working prototype with live users is an asset, not a draft, and treating it as a draft is expensive.

And no promise of keeping the speed of the first weeks. That speed was paid for with what now has to be built.

How to start

Tell me how many live users the product has and what happens if it does not work tomorrow morning. Those two answers show which half of the work comes first.