A prototype that feels like a product still isn't one

The demo always goes well. The screen looks real, the buttons click, the data looks plausible, and the room nods along. Then someone asks the only question that matters — "great, can we put it in front of customers next week?" — and the floor quietly drops out. Anyone in the room who has shipped software before knows why. A prototype that feels like a product still isn't one, and the distance between the two isn't a polish pass. It's the entire job.

This gap has always existed. What's new is how fast you can now reach the near side of it. AI code generation can turn a sentence into a clickable app in an afternoon. That's genuinely useful — and it's also the trap. The faster you can produce something that feels finished, the easier it is to forget how much of "finished" was never on the screen in the first place.

What a demo proves, and what it quietly skips

A demo proves two things: the idea is worth building, and the happy path works. It shows a frontend and just enough backend to make that happy path move. One user. No load. No malicious input. No second day.

Production is everything the demo got to ignore. It's worth being concrete, because "production-ready" is a phrase that hides its own weight. Real production — anywhere near an enterprise — has to answer:

• Who's allowed to do this? Authentication, roles, and permissions, so the intern can't trigger the thing only finance should.
• Where does it run, and does it stay up? Hosting, compute, caching, and rate limiting — under real traffic, not a single click.
• How does it change without breaking? Version control, CI/CD, and a rollback you can actually pull when the new version is worse than the old one.
• How do you know what it did? Observability, logs, and alerts — so you find out from a dashboard, not from an angry customer.
• Can you prove it later? Audit trails, compliance, and SLAs — the evidence a security review, a regulator, or a customer's procurement team will ask for.
• What does it cost to keep running? Visibility into spend before the invoice, not after.

The demo had a frontend and a backend. Production has all of that plus the layers underneath it. None of them show up in a screenshot, which is exactly why they're so easy to underestimate and so expensive to bolt on later.

Why the gap feels smaller than it is

Here's the uncomfortable part: the tooling that makes the demo fast doesn't touch the part that makes production slow. Generating the code was never the bottleneck for serious software — standing it up safely was. So when a tool compresses "build the demo" from two weeks to twenty minutes, the visible work shrinks dramatically and the invisible work doesn't move at all. The result is a wider gap between how done it looks and how done it is.

Make it concrete. Picture an agent that drafts a customer refund. The demo is trivial — it reads an order, writes a polite message, proposes an amount. Now ship it. Who is actually allowed to issue the refund (permissions)? What stops it from issuing the same refund ten thousand times (rate limiting, idempotency)? When it refunds the wrong order, how do you pull it back (rollback)? When finance asks "who approved this, and on what basis," what do you hand them (audit)? When it quietly starts costing more than it saves, how do you see that (cost)? The model wrote the easy part. Every one of those questions is the work.

OBTO's take: make the stack the default, not a six-month project

This is the problem OBTO was built around, so we'll be direct about where we fit — and where we don't.

OBTO's premise is that the thing you describe and ship should land on the production stack, not next to it. The same primitives that produce a demo also carry the production concerns:

• Tools and pages are versioned data, not a binary you redeploy. Changing something is a diff you can roll back — so versioning and rollback aren't a separate system you bolt on; they're how the platform already works.
• Every action leaves a Glass Receipt — a per-call record of who ran what, against which record, with what result. That one mechanism is most of observability, most of an audit trail, and most of the evidence a compliance review asks for, by default rather than as an afterthought.
• Auth, roles, and secrets live at the boundary, server-side. Permissions and security are enforced below the interface, so they hold no matter which client calls in.
• Hosting, scaling, and caching are the platform's job, not yours. You bring the model and the idea; the place it runs is already there.

What OBTO does not do is make the stack disappear. You still own the design, the domain logic, and the judgment calls — what the refund rules should be, who approves them, what "done" means for your business. We're honest about that, because anyone promising that AI removes those decisions is selling the demo, not the product. What OBTO removes is the six-month detour of assembling the stack underneath them from scratch.

That's the whole argument. Generating code is the easy ten percent now, and it keeps getting easier. The other ninety percent — the layers no screenshot shows — is why a team that "shipped" something impressive in a weekend can still be nowhere near production a quarter later. Closing that gap on purpose is the actual work. Describe it, ship it, and own the whole stack — not just the part that demos well.

When you want to see what those production layers look like when they come standard, getting started puts a governed tool and a real receipt in front of you in minutes, and pricing starts at zero. It's the same thesis behind why we engineered around vendor lock-in and how we compare the build-it-fast tools honestly.

Frequently asked questions

What's the difference between a prototype and a production app?

A prototype proves the idea and the happy path — usually a frontend and minimal backend, for one user under ideal conditions. A production app adds everything the prototype skipped: authentication and permissions, hosting and scaling, CI/CD and rollback, observability, security, audit and compliance, and cost control. The prototype is the visible part; production is the stack underneath it.

Why do vibe-coded or AI-generated apps struggle to reach production?

Because AI code generation compresses the visible work (building a working demo) but not the invisible work (running it safely). The gap between "looks finished" and "is finished" actually widens, because the production stack — auth, audit, rollback, monitoring — didn't get any smaller.

What does enterprise production actually require?

At minimum: identity and access control (IAM/RBAC), data storage, hosting and compute, CI/CD and version control, security and secrets handling, rate limiting and caching, observability and alerting, rollback and recovery, and audit, compliance, and SLAs — plus visibility into what it all costs.

How does OBTO help get from prototype to production?

OBTO makes the production layers the default: versioned tools-as-data (rollback built in), a per-call Glass Receipt (observability and audit), server-side auth and secrets, and managed hosting. You still own the design and domain decisions; OBTO removes the work of assembling the stack underneath them.

Is a working demo close to a shippable product?

Closer in appearance than in reality. A demo can be 90% of what you see and 10% of what you have to build. The remaining work — making it secure, observable, recoverable, and auditable under real conditions — is most of the effort and most of the risk.