The hard part was never the code

You can build a working demo of your product this weekend, for next to nothing, without writing a line of code. That is genuinely new, and genuinely remarkable. It is also the reason more founders than ever are about to waste a fortune.

We build products for a living, so let me be blunt about what has changed and what has not. Building software has always divided into an easy 20% and a hard 80%: the demo, and then everything that makes it hold up once real users, real data and real money arrive. What is new is that AI coding tools have taken that easy 20%, the clickable prototype, the thing that looks finished in a screen recording, and made it nearly free. The hard 80%, the part that was always the actual product, they have barely touched. If anything, they have made it harder, because there is now a flood of impressive-looking software with nothing underneath it.

The demo has never been cheaper

The numbers here are real and they are staggering. A solo founder can stand up a functional SaaS prototype for a few hundred pounds using AI app builders, against tens of thousands for a traditional custom build. The tools themselves are growing faster than almost anything in software history: Lovable reportedly reached $20m of annual recurring revenue in two months, the fastest-growing European start-up on record, and Bolt.new hit around $40m within six.5nxcode.ioLovable vs Bolt.new 2026: AI App Builder ComparisonNxCode, March 2026Visit source →

This is not hype you can safely ignore. If your instinct is still that you cannot build real software this way, you are fighting the last war. You can get to a real, testable, in-front-of-users prototype astonishingly fast now, and every founder should be doing exactly that before they spend serious money. But notice the word. Prototype.

The cliff between it works and it works in production

Here is what the weekend demo does not show you. The moment real users, real data and real money arrive, the ground changes. A prototype has to work once, for you, on a happy path you control. A product has to work every time, for people you have never met, on data you did not anticipate, when a third of the inputs are malformed and someone is trying things you never imagined.

Between those two things sits everything that actually makes software a business: authentication that cannot be bypassed, data that cannot leak, error handling for the cases you did not think of, a bill that does not quietly triple, and an architecture you can still change in six months.

The industry has started counting the cost of ignoring this. Salesforce Ben's 2026 predictions piece is titled, plainly, It's the Year of Technical Debt (Thanks to Vibe-Coding).2salesforceben.com2026 Predictions: It's the Year of Technical Debt (Thanks to Vibe-Coding)Salesforce Ben, January 2026Visit source → An analysis of 8.1 million pull requests found that technical debt rises by between 30% and 41% after teams adopt AI coding tools, concentrated in a few nasty patterns: missing error handling, duplicated logic, and functions that work but that nobody actually understands.3getautonoma.comVibe Coding Technical Debt: The 90-Day ReckoningAutonoma AI, 2026Visit source →

Nobody decides to ship the throwaway prototype to paying customers. It just happens, one "while we're here" feature at a time, until the demo is the codebase and there is no foundation underneath.

The uncomfortable data on AI coding

Even the productivity story is more complicated than the marketing suggests. In a carefully run randomised controlled trial published in July 2025, the research nonprofit METR found that experienced open-source developers were actually 19% slower when allowed to use AI tools on codebases they knew well. The striking part: those same developers had forecast a 24% speed-up beforehand, and even after finishing still believed AI had made them about 20% faster.1metr.orgMeasuring the Impact of Early-2025 AI on Experienced Open-Source Developer ProductivityMETR, July 2025Visit source → The perception gap was larger than the effect itself. METR has since published follow-up data suggesting later 2025 tools look more favourable, so treat the exact figure as a moment in time, not a law of nature.

The point is not that AI coding is bad. We use these tools every day and they are genuinely powerful. The point is that speed you can feel is not the same as progress you can measure. The tools are brilliant at generating code. They are indifferent to whether that code should exist, whether it is safe, and whether you will be able to maintain it once the person who prompted it has moved on. It is worth remembering that in Stack Overflow's 2025 developer survey, 84% of developers use or plan to use AI tools, yet more of them actively distrust the accuracy of what those tools produce than trust it.4survey.stackoverflow.co2025 Developer Survey: AIStack Overflow, 2025Visit source →

The hard part was never the code

Here is the thing the current moment obscures. Writing code was never the expensive part of building a good product. The expensive parts were deciding what to build, designing how it should work, making it reliable under real conditions, and building something a competitor cannot copy in a weekend. AI has made the cheap part cheaper. It has done almost nothing for the expensive parts. In fact, by making it trivial to generate more software faster, it has raised the premium on judgement, on knowing what not to build.

Which brings us to the question every founder should be asking in 2026: if anyone can generate your product in an afternoon, what stops them?

Defensibility, when the model is rented

The AI wrapper critique is loud right now, and mostly correct. If your product is a nice interface over someone else's model and a clever prompt, you do not have a moat. You have a head start, and a short one. The simplest test doing the rounds is a good one: if a technical user can paste your core prompt into a chatbot and get most of your output, you are a feature, not a company.6buildmvpfast.comAI Wrapper Startup? Build a Defensible Business in 2026BuildMVPFast, 2026Visit source →

The defensibility, when the model itself is a rented commodity, lives everywhere except the model. Proprietary data that compounds the longer you run. Deep integration into a workflow that becomes painful to rip out. A product that measurably improves the more a specific customer uses it. None of that comes from a code generator. All of it comes from judgement, design and the unglamorous engineering underneath.

Where founders should actually spend now

So the advice inverts. Spend nothing proving the idea. Use the cheap tools, build the throwaway prototype, put it in front of real users this month and learn whether anyone wants it. That is the best use of AI app builders there has ever been, and skipping it is its own kind of waste. It is what an MVP is for, and it has never been cheaper to run that test.

Then, when the prototype has earned it, spend money on the things AI made scarce, not the things it made free. Spend on the architecture that means version two is an addition rather than a rebuild. Spend on the reliability, the security and the cost controls that turn a demo into something people trust with real data. Spend on the design and the workflow depth that make you hard to replace.

That is the shape of a build worth paying for now. Not the code, the code is nearly free, but the judgement about what deserves to be built and the engineering that makes it last. Build the smallest real thing, prove it, then build the parts that are hard on purpose. The demo is free. The product still is not.