More companies are arriving at our first call with something already built. An operations manager spent a few weekends with an AI coding tool and has a working app. A team assembled a no-code system that runs a real process. A contractor delivered an MVP that customers are using. And now it is slow, or fragile, or nobody can change it, or the person who made it is gone, and the question is: what do we do with this?
The first thing to say is that you did something valuable. The second is that what you built is a prototype, and prototypes are not products. Knowing the difference is how you decide what to do next without either throwing it away or pouring money into a thing that cannot hold it.
What the prototype proved
A working prototype answers questions that a requirements document never can.
It proved the workflow. People used it, so you know what the process actually is, not what the org chart says it is. It proved demand. If customers or staff adopted it, the thing is needed. It proved the screens. The layout everyone argued about is settled, because it exists and people have opinions about it. And it surfaced the edge cases, the exceptions that only show up when a real person types a real thing into a real field.
Every one of those is expensive to learn any other way. A company with a used prototype is months ahead of a company with a slide deck. Do not let anyone, including us, treat it as a mistake.
Where prototypes hit the ceiling
The ceiling is not about the tool that made it. AI-generated code, no-code platforms, and hand-built MVPs all hit the same walls, for the same reason: they were built to prove something works, not to keep working under load, change, and time.
It handles the happy path. A prototype does what it was shown to do. It does not handle the order with no customer attached, the upload that is forty times bigger than expected, or the two people editing the same record at once. Production is mostly edge cases.
Nobody can safely change it. There are no tests, so every change is a guess. The structure grew as features were added, so a change in one place breaks something in another. AI-generated code is particularly prone to this: it is fluent, and it is often subtly inconsistent with itself in ways nobody reviewed.
It has no security posture. Credentials in the code. Everyone is an admin. No audit log. No thought given to what happens when someone leaves. For a tool three people use, that is tolerable. For a system with customer data, an insurer, or a sponsor, it is a liability that shows up in diligence.
It does not scale, and it does not recover. Works with a thousand records, not a hundred thousand. Works until the platform it runs on has an outage, and then nobody knows how to bring it back. No backups, or backups nobody has tested.
It depends on one person. The manager who built it, or the contractor, is the only one who understands it. When they are busy or gone, the system is frozen.
The platform is the limit. No-code tools in particular have a point where the thing you need is the thing the platform will not do, and the workaround is worse than the problem. Pricing also tends to climb with usage in ways that were invisible at prototype scale.
What production actually needs
The gap between a prototype and a product is not features. It is the things that make features safe to depend on.
- A structure that can be changed without breaking, and tests that prove it
- Proper handling of errors, edge cases, and bad input
- Security: authentication, permissions, secrets management, an audit trail
- Infrastructure that is monitored, backed up, and can be restored
- Performance that holds as the data and the users grow
- Documentation, and more than one person who understands it
- A plan for keeping it current, which is what Budgeting for software maintenance is about
None of that is visible in a demo. All of it is what you are paying for when you pay for a product instead of a prototype.
The honest next step: a System Evaluation
The mistake we see most is guessing. Either “it works, let’s just keep adding to it” until it collapses, or “it’s a mess, throw it out and start over” before anyone has looked. Both are decisions made without facts.
A System Evaluation is the fact-finding step. Fixed fee, one to four weeks. We look at the architecture, the code, the infrastructure, and the security, and we come back with findings, a prioritized plan, and a fixed proposal for the next step. The plan is yours whether or not you do the next step with us.
The outcomes land in roughly three places.
Harden it. The prototype is sounder than it looks. The fix is tests, security, infrastructure, and cleanup, and the business keeps what it has. This happens more than people expect, especially with well-made no-code systems that just need a proper backend or integration layer around them.
Rebuild the core, keep the learning. The structure will not hold, but the screens, the workflow, and the edge cases are all known. That is the input to a new build, and it makes the design phase dramatically faster, because the prototype already answered the questions a VDP Sprint usually has to discover. The prototype becomes the spec.
Replace the platform. The tool it runs on is the ceiling. The plan is a migration to something that can carry the business, with the prototype running until the replacement is ready.
Whichever it is, you decide with a written plan and a fixed number, instead of after the next outage.
When it is already off the rails
Sometimes the situation is not “we have a prototype and want to know what to do.” It is “we have a system in production, it is failing, the people who built it are gone or not answering, and the business is exposed.” Customers are affected. Someone is manually patching data every morning. There is a deadline.
That is a Project Rescue, and it runs differently. The first job is to stabilize: get into the system, stop the bleeding, make sure there are backups, and get the business through the week. Then the evaluation, then the plan. We have taken over enough of these to know that the first two weeks are about control, not architecture.
If that is where you are, do not wait for a scheduled call. Reach out today and say the word rescue.
What not to do
Do not keep building on the prototype because it is cheaper this month. Every feature added to a structure that cannot hold it costs more to move later.
Do not throw it away in frustration. Whoever built it captured months of learning, and that learning is the most valuable thing you own right now.
Do not ask the person who built it whether it is production-ready. Not because they will lie, but because “production-ready” is a judgment that needs a second set of eyes, ideally eyes that have seen a hundred of these.
The first step
Bring the prototype to a Discovery Call. Thirty to sixty minutes. We will want to know what it does, who uses it, what is breaking, and who built it. If it needs an evaluation, we will say so and tell you what it costs. If it is genuinely fine for what it is, we will say that too, and tell you what to watch for.
You built something that works. Now let’s find out what it will take to make it something you can rely on.