Earlier this year I wrote about a question I ask clients who want to build their own software: Are you ready to become a software company? Since then, fewer people ask whether they should build. They arrive with something already built and want to know how close they are.
Usually they're further than they think. Take Morgan, a composite of a few of them. She runs a freight brokerage and spent three weekends building a tool that matches loads to carriers. It has a login, a dashboard, a real database and a public URL. Her two biggest carriers already use it, and one has asked when he can start paying. From the outside it looks like a product, and Morgan believes it is one.
What a Prototype Proves
A prototype tells you whether an idea holds up when someone uses it. Getting that answer in a week instead of a quarter is a real gain from AI-assisted development. Morgan's tool works because Morgan uses it the way Morgan expected it to be used: her own lanes, her own data, and two carriers who liked her and wanted it to work. A good demo shows there's demand. It says very little about how the software behaves once strangers start using it.
What a Product Owes Its Users
A prototype owes nobody anything. When Morgan's tool dropped a week of load history, she reloaded a spreadsheet and moved on. Her carriers can't do that, and one of them has already stopped keeping his own records. A product has customers who can't see inside it and have built part of their business around it working.
Prototype | Product | |
|---|---|---|
Users | The builder and a few friendly testers | Strangers using it in ways nobody predicted |
Data | Seed data you can throw away | Customer records that survive every deploy and outage |
Failure | Someone refreshes the page | An alert fires, someone is paged, the customer hears what happened |
Security | One admin login and keys in the code | Role-based access, managed secrets, a pen test the buyer will ask for |
Ownership | Whoever wrote the prompts | A team that knows the code well enough to change it safely |
Almost nothing in the right-hand column is visible to a customer, which is why it gets underestimated. At Precocity we judge software on whether it's valuable, useful, trustworthy and enjoyable. A prototype can manage the first two. Trustworthy and enjoyable come from work that won't show up in a demo or prototype.
Why Hardening Rarely Works
The usual plan after a good demo is to fix the bugs, add authentication and call it v1. Sometimes that works. More often the shortcuts turn out to be structural. When Morgan signed a second brokerage, she asked for a login for them and a way to keep the two apart. There was no "them" in the code. Every query, API call and background job assumed one company, and retrofitting that means touching all of them. Miss one and the second brokerage sees the first one's rates.
Vibe-coded prototypes have an extra problem. The model made the architectural choices, often inconsistently from one session to the next, and nobody on the team can explain them. Asked why the matching logic lives in three different files, Morgan can only say that's where the model put it. I tell clients to treat the prototype as a specification. It shows exactly what the business wants, which is more than most requirements documents manage. Plan the product build as if none of the code survives and count whatever does as a bonus.
What the Product Build Requires
The second build answers a different question: will this keep working for people you'll never meet? Start with architecture, deciding on purpose how tenants are separated, where permissions are enforced and where the API boundary sits for the integrations buyers will expect. Automated tests and a release pipeline with staging and rollback come next, and they matter more when nobody wrote the code line by line.
Security has to live in the platform, with secrets out of the codebase and backups you've actually restored from. If you sell to larger companies, expect a SOC 2 request. You also need searchable logs, alerts that reach a person and an agreed answer for who gets paged at 2 a.m.
Then there's design for people who weren't in the room. Morgan never saw an empty dashboard; hers had loads in it from day one. The third brokerage logged in, saw a blank screen, and emailed to say it was broken. Someone also has to own the code, whether that's an internal team or a partner, well enough to change it safely and keep a roadmap moving.
Software Isn't a Building
Most people think about software the way they think about construction. You design it, build it, hand over the keys, and spending drops to occasional upkeep. Software doesn't work that way because its surroundings keep moving. Dependencies ship security patches, cloud providers retire services, partners change their APIs, and customers want what a competitor launched last month.
Shipping v1 is where the rock reaches the bottom of the hill and the pushing starts. Morgan's budget had one line on it, the build, and nothing for the years that follow. Within a couple of years the original build is usually the smallest line in the budget. When clients ask what a product will cost, I care less about the v1 number than about what it takes to run and improve the product every year after, and whether the business can carry that for the product's whole life.
Build the Prototype Anyway
A prototype settles whether anyone wants the thing, which is one of the most expensive questions in software, at the point where it's cheapest to answer. Morgan's did exactly that: three brokerages, one of them paying, before anyone wrote a requirements document. Then budget the product build as the real one and expect the years after launch to cost more. The people doing that work should be experienced and have taken software to production before.
And not to sound too self-serving, but that is the strength of Precocity. Give us a call, or whatever you do in this modern, digital age to reach out.
