Your AI prototype is not a product. Stop selling it like one.

If your app only works while the person who prompted it is on the call, it isn't finished.

I build software and use AI tools. Getting from an idea to something you can click through faster is useful. It lets you test an idea before spending months on it.

What bothers me is the next leap: a working demo gets presented as a finished business system, and everyone quietly stops asking who will look after it.

That distinction matters a lot more now that companies are starting to replace software purchases with things they build themselves.

The build-it-yourself argument just got much bigger

McKinsey's August 25 State of AI survey reports that 32% of respondents say their organizations decided against buying at least one software product or feature because they could build it internally using coding agents. Eighty percent report better personal productivity. Yet the share reporting a positive company-wide earnings impact from AI was 37%, essentially unchanged from the previous year.

Those are survey responses, not an audit of every company's returns. The research covered 1,719 participants across 97 countries, with responses collected in May and June. It doesn't establish that coding agents caused the gap between personal productivity and company results. It does make the gap worth discussing.

My concern is what happens when someone reads the first number and treats it as permission to ignore everything after the initial build.

A subscription invoice is easy to see. The employee who spends Friday repairing an internal tool is much easier to overlook. So are the access requests, the broken integration and the report that nobody trusts enough to send without checking it manually.

If those hours disappear from the comparison, building your own software will look wonderfully cheap.

The demo skips the awkward parts

Imagine a small customer portal. This is a hypothetical example, but the questions are ordinary ones.

The demo looks good. A customer signs in, uploads a document and sees a neat dashboard. Great. Now have a second customer sign in. Can they reach the first customer's files by changing an address? What happens when an upload stops halfway through? Can somebody leave the company without keeping access forever?

Then try a payment arriving twice, an expired login, an unavailable email service and a restore from yesterday's backup.

None of that is an argument for making a prototype complicated. A prototype is allowed to be rough. Its job is to help you learn. The problem starts when real customer data and real business promises arrive while everyone is still treating it as an experiment.

A polished interface can hide an unfinished system very well. AI has made the polished interface easier to produce.

More code can mean more work downstream

In a June report commissioned by New Relic, 78% of surveyed technology leaders reported more incidents after shipping AI-generated code, and 86% reported senior staff spending more time fixing it. Hanover Research surveyed 200 US technology decision-makers at larger companies already using AI in software engineering.

That's a vendor-sponsored survey of managers, not a controlled experiment or a prediction about your next project. New Relic sells monitoring software. The findings deserve that context. They also describe a cost that a stopwatch attached to code generation will miss.

Someone still has to understand what changed, decide whether the behavior is right and work out what to do when it isn't. Generating the first version faster is valuable. Generating tomorrow's support queue faster is less impressive.

And no, I don't think the answer is to ban AI coding. In its February 2026 research update, METR said developers were probably benefiting more from AI than its early-2025 study suggested, while warning that selection effects made the newer results hard to interpret. Repeating an old slowdown headline as a universal verdict would be just as lazy as believing every speed claim in a launch video.

The useful question is how much dependable work gets finished after review, fixes and support are included.

Ask who owns Monday morning

Before a prototype becomes something your business depends on, get clear answers to a few unglamorous questions.

• Who owns the accounts? Your business should know where its code, domain, hosting, database and paid services live, and how to access them.
• What has actually been checked? Ask to see the important customer journeys, permission boundaries and failure cases being tested. A green screenshot alone tells you very little.
• Who finds out when it fails? A working alert needs a recipient who has agreed to respond. Otherwise, your first monitoring system is an annoyed customer.
• Can someone restore it? A backup is more convincing when somebody has successfully restored it.
• What will it cost to keep? Include hosting, AI usage, maintenance and the time your own staff will spend operating it. Revisit the estimate when usage changes.

The answers can be proportionate. A disposable internal experiment doesn't need the same arrangements as a paid service holding customer records. But the person making that decision should understand the difference.

I'd also ask one question that tends to cut through a very smooth sales pitch: if you stop working on this tomorrow, what exactly do I have?

Let prototypes be prototypes

There is plenty of room for quick experiments, tiny tools and software built by people who have never called themselves developers. That's one of the good things happening here.

There is also room to charge for the work of making those tools dependable. That work doesn't become unnecessary because the first version arrived quickly.

At Rosecraft, the work I want people to look at includes the less photogenic details: returning-user behavior, integrations, deployment and the scope of what was actually delivered. You can see examples in our portfolio.

Use AI. Build the experiment. Find out whether anyone needs it.

Then, before you sell it as a product or make your company depend on it, give somebody ownership of what happens after the demo.

The launch video ends. The software keeps running.