Can we just use this?

Someone describes what they want. A working interface appears on screen within minutes. Stakeholders click through it, the workflow makes sense, and there is a genuine and entirely reasonable feeling that something substantial has been created.

Then the question arrives, and it is always the same question, asked cheerfully by someone who means it kindly.

Can we just use this?

That is where the money starts leaking, and the leak is invisible for a surprisingly long time because everything looks fine.

What is on the screen#

The demonstration is convincing precisely because everything absent from it is invisible. You cannot see what has not been done, and the parts that have not been done are the parts that do not photograph.

Consider what stands between that interface and something you could put in front of real users. Error handling that says something useful rather than a generic apology. Behaviour when two hundred people arrive at once rather than three. Data validation, because users will type things nobody anticipated, and they will do it on the first morning. Security beyond hoping nobody looks. Audit trails, because someone will eventually ask who changed that figure and when. Accessibility, so the application works for people who navigate by keyboard or screen reader. Integration with the systems that already hold your data. Deployment, monitoring, recovery when something fails at three in the morning. And documentation good enough that a person who is not the original author can maintain it, which is the whole ballgame if the thing survives more than a year.

None of that appears in the prototype. All of it is required. The visible portion of the work is perhaps forty per cent of delivering something real, and the ratio gets worse the more the thing matters.

I use icebergs reluctantly because everyone does, but the reason it persists is that it is accurate: the interesting part is under the waterline, and the part under the waterline is what sinks you.

The constraint that never gets discussed#

There is a second problem, quieter and in some ways more consequential.

Most of these tools produce web applications. That is what they are good at and what they default to. Which means that by the time anyone has seen the prototype, an architectural decision has been made, by the tool, before requirements were understood, and nobody in the room experienced it as a decision at all.

Perhaps your users are in a warehouse with unreliable signal and need something that works offline. Perhaps the data volumes make a browser the wrong place to do the processing. Perhaps this should be a scheduled job with no interface whatsoever, and the fact that everyone is looking at a screen is itself the mistake.

Those conversations do not happen, or they happen far too late, once stakeholders have formed an attachment to something they have already touched. Hand a mechanic a hammer and tell them it is the only tool available, and they will find a way to use it on everything, and some of those jobs will go badly.

Technology choice should follow architectural requirements. When the prototyping tool sets the technology before requirements exist, you have reversed the order, and reversing that order is how you build the wrong thing very efficiently.

Where these tools are genuinely excellent#

Having said all that, dismissing them would be foolish, and I want to be clear that I use them and would defend them.

They are outstanding at a problem that has plagued software delivery for as long as I have been in it: getting people to articulate what they actually want. I have watched someone with no technical background produce something in an afternoon that six weeks of requirements workshops had failed to extract, because they could finally show rather than describe.

That is worth a great deal. Misunderstandings surface immediately rather than eight months in. Feedback on something clickable is enormously more useful than feedback on a forty page specification, which mostly generates comments about the specification. And a stakeholder who can demonstrate "something like this, but the totals need to be here" has communicated more in ten seconds than any document achieves.

The distinction that matters is that you have built a communication tool, not a product. A storyboard is not the film. Both are valuable, both are necessary, and the storyboard is not a smaller version of the film that merely needs finishing.

Where it belongs in the process#

Position these tools in discovery and design, where they earn their place, and not in delivery, where they create expensive misunderstandings.

Use them to validate a concept before committing to architecture. Let the prototype inform the specification and the technical decisions. Then build the actual system with appropriate technology, treating the prototype as living documentation of intent rather than a foundation to be extended.

That last point is where most of the damage occurs. A prototype handed to a development team with the words "it is mostly there, just needs tidying" sets up a conversation that will go badly for everyone. The team is now arguing that the visible thing is not the real thing, against stakeholders who have seen it working, and that is an argument you cannot win with words. Better to establish before anyone builds anything that this is a sketch, valuable as a sketch, and not a partial building.

The honest test#

If you believe your prototype could become production software with minimal further work, one of two things is true. Either the requirement is genuinely simple, in which case wonderful, get on with it. Or you have not yet found what is missing.

I would not want to bet on the first, and I have never regretted assuming the second.

There is a version of this technology's future where it settles into the right place, becomes the standard way requirements get explored, and quietly removes an enormous amount of waste from the front of every project. I think that is likely, and I am looking forward to it. Getting there requires everyone in the room to understand precisely what they are looking at, which costs nothing except the willingness to say so before the question gets asked.