A prototype is not a system. Here is the difference.

You can now describe an app in plain English and have a working version in front of you the same afternoon, without writing a line of code. That part is real and it is new. What has not changed is that building the thing was never the hard part of owning it. A prototype's job is to make a vague idea concrete enough to argue about; a system's job is to keep working on a Tuesday when everyone is busy. Three questions decide which one you have.

What actually changed, and what did not

The build cost collapsed. That is the genuine shift, and it deserves more credit than the sceptics give it.

Free hands on build sessions are running all over south east Queensland at the moment, and they are good events. Somebody walks in with an idea and walks out two hours later with something that works. That is a far better use of an evening than another webinar about the future of work, and we would rather a business owner went to one than read another article about what is coming.

What did not change is everything downstream of the build. The thing that worked in the room still needs somewhere to live. It needs a decision about what data goes into it. It needs someone to fix it when it breaks, because it will. And it needs a reason for a person to open it a second time.

None of that is hard, exactly. All of it is unglamorous, all of it has to be somebody's job, and none of it fits in a two hour session.

Why do good prototypes quietly die?

The usual ending is not a bad app. It is a good app that stops being used.

Here is the shape of it. Week one, everyone is pleased. Week two, someone hits an edge case the demo never covered and works around it manually. Week three, the workaround is faster than the app for that case, so they use the workaround for everything. Week four, the app is a tab nobody opens.

Nothing failed. The thing simply never acquired the properties that make software survive: somewhere to live, an owner, a way to change, and a job it does better than the alternative on a bad day rather than a good one.

The owner's conclusion, though, is usually much broader than the evidence supports. "We tried AI and it did not stick." What actually happened is that a prototype was asked to behave like a system, which is a category error, not a verdict on the technology.

The framing: a prototype is an argument you can click on

This is the reframe we come back to, and it changes what you do next.

A prototype is not a small system. It is a different object with a different job. Its value is that it turns a vague idea into something concrete enough to argue about, and an argument about a thing you can click beats ten meetings about a thing you cannot.

Which means most prototypes should die, and that is the prototype succeeding. If you build the thing and looking at it tells you the idea was thinner than it sounded, you have just saved yourself a project for the price of an afternoon. That is the cheapest outcome available anywhere in this work.

Judge a prototype on what it settled, not on whether it survived.

The boring pass: three questions before it is real

For the ones that do survive the argument, there is a pass to do, and the boring pass is most of the work. Before you use the thing for real, answer three questions in writing.

1. What data goes into it?

Real customer names, or made up ones? Where does that data sit once it is in there, and who else can reach it? A prototype built on invented sample data and a prototype built on your actual client list are the same app with entirely different obligations. This is also where a two hour session is least likely to have helped you, because the answer depends on your business, not the tool.

2. Who fixes it when it breaks?

Not "will it break", which it will. Who. By name. If the answer is the person who built it and they are the only one who understands it, you have a system with a single point of failure who also takes annual leave. Write down where it lives, what account it runs under, and how someone else would get in.

3. What does it replace?

This is the one people skip and it is the one that decides everything. If the app replaces nothing, if it is additive, it will not survive a busy week however good it is, because in a busy week people do the thing they already know how to do. Something has to come off the list. Name it.

If it helps, we have written about the related trap of building something that cannot bend when the business changes, in AI automation that adapts, and about the difference between a simple workflow and something more autonomous in is it an AI agent or a workflow?.

How long should the boring pass take?

Less time than people fear, which is why it is worth naming as a step rather than leaving it to happen by accident.

For a small internal tool it is a conversation and a page of notes, not a project. The reason it gets skipped is not cost, it is that it arrives at the exact moment everyone is pleased with themselves and does not want to talk about backups. That mood is the whole risk.

At Handiwork the boring pass is the difference between a demo and something still running in six months, and it is the part nobody sells tickets to. It is also, unhelpfully for marketing, the part clients value most in hindsight and least in advance.

Speed and durability are not opposites here, incidentally. We have argued before that useful AI work lands in weeks rather than months. The point is that the weeks include the boring pass rather than skipping it. Our pillar on practical AI workflows for small business sets out the wider picture, and the use cases page shows what this looks like once it is running.

So should I go to the build session?

Yes. Go.

Just be honest about what you came home with. You came home with an argument you can click on, which is genuinely valuable and is not the same as a business system. Use it to settle the question it was built to settle. Then, if it survives, do the boring pass before anybody depends on it.

Ready to find out where you stand?

Our free AI Readiness Check takes about five minutes and helps you work out which of your ideas is worth making real: start the AI Readiness Check.