When the Prototype Becomes the Operation

Six months ago, your ops lead built a tool in Cursor to track where every new customer is in onboarding. 

The tool handles the handoff from sales, the kickoff meeting, the integration steps, the go-live checklist, and the moment the customer becomes customer success's responsibility. 

The team adopted it in the first week and stopped opening the project tracker leadership thinks they still use.

Last week she went on vacation, and the customer success lead asked who was going to update the tool when the new customer signed on Friday. 

She discovered that nobody else had been trained on it, the login was in her personal Google account, and the Slack channel where the team coordinated around it was a side channel she had set up. 

The tool is now the system of record for how every new customer reaches go-live, and the only person who knows how any of it works is on a beach for ten days.

This is the moment the prototype became the operation. 

It is happening across growth-stage companies right now, and the conversation about it usually starts the same way: somebody on the team built something useful with an AI tool, the business adopted it, and the company ended up dependent on it without anyone ever signing off.

The right move when you find one has an order. 

The teams that get it right keep the value the prototype already produced and add the engineering it skipped.

‍

Why this is happening more in 2026

AI made building software almost trivially easy in the last eighteen months. Andrej Karpathy named the phenomenon in February 2025 when he posted on X about building software without thinking about the code itself, just describing what he wanted. 

He called it "vibecoding." 

The term traveled fast because everyone in software had been doing some version of it for at least a year.

The tools that did it have names you have heard at this point: Cursor, Lovable, Bolt, Claude Code, Replit Agent. 

Cursor crossed $100 million in annual recurring revenue inside eighteen months of launching, and the user base now includes product managers, designers, and operations leads alongside the engineers it was originally built for. 

The common feature across all of these tools is that someone with no engineering training can sit down on a Tuesday and have a working application by Friday. 

The output looks legitimate, the UI is clean, the basic workflow runs.

That is good news for prototyping. It is also why the prototype-to-production accident has gotten common enough to need its own name. 

The barrier between "I built a thing" and "the business depends on the thing" used to be the engineering team. Engineering would scope it, security review it, integrate it, document it, take ownership. 

None of that has to happen anymore for a tool to start running real business operations.

The pattern is consistent: someone builds, the team adopts, nobody escalates. 

By the time leadership notices, the operation is on the prototype, and the conversation about what to do with it is overdue.

‍

What the prototype is good at, and what it is not

The instinct, when you find a prototype like the onboarding tool, is to throw it out and have engineering rebuild it from scratch. 

That instinct is expensive, because the prototype is doing the part of a software project that usually costs the most: discovery.

Your ops lead spent six months learning what works inside the operation, and the tool is the record of what she learned. 

It captures which handoffs are real and which exist only on paper, which customers need extra attention in the first week, what "go-live" actually means inside your specific company, and what the team has always wished the official systems would do. 

That work would take a software firm three to six weeks to recreate from interviews and process documentation. 

The prototype gives it back for free, in a form that already works.

The part the prototype skipped is the engineering. Auth, error handling, audit trails, security review, scaling, the integration with the rest of the stack, the documentation, the recovery plan when something breaks. 

That work is necessary, and it does not produce itself.

The right move is to keep the prototype as the spec and treat engineering as the build that comes next. 

The teams that get this right preserve the discovery work the ops lead already did and add the protection she did not.

‍

What breaks when a prototype becomes production

The actual costs of running on an unfinished prototype rarely show up for months. 

When they show up, they show up at the worst time, usually in front of a customer or an auditor, and the senior team that gets the call is the one that did not build the prototype and does not know how it works. 

The most common failure modes:

• Auth and access control. The prototype was built by one person for the team they trusted. The access model is "anyone with the link." That becomes a problem the first time someone outside the team accesses customer data they should not see, or the first time the auditor asks for an access log.
• Data integrity. The prototype was not built with validation, foreign key constraints, or backup. The first time someone enters a customer's email in the wrong field, the records drift and there is no good way to clean them up. By the time anyone notices, the operation has been working off bad data for months.
• Integration with the rest of the stack. The prototype lives in its own world. It does not talk to the CRM, the billing system, or the data warehouse. The team is keeping two records of every customer manually, one in the prototype and one in Salesforce, and the workarounds are stacking up around the gap between them.
• Scaling. The prototype was built to handle the load on a Tuesday. It does not handle the load when the business doubles, and the first time it falls over is the first time anyone has thought about how it should handle that volume.
• Knowledge concentration. Only the original author knows how it works. When they leave, take vacation, or move teams, the operation has nobody who can fix it. The dependency that nobody planned for becomes a single point of failure.

Each one is solvable. 

None of them solve themselves. 

The longer the prototype runs without the engineering layer underneath, the more expensive each fix becomes, and the more likely the first time leadership sees one is the first time a customer does.

‍

The right way to handle this when you find it

When leadership realizes the operation is depending on a prototype, the first move is to take inventory. 

The team's instinct will be to either rebuild from scratch or leave it alone, and both miss what the prototype actually offers.

The walkthrough takes about an hour and surfaces three things:

• What the prototype does and what part of the operation it owns. Map it to the actual workflow the team is running on it.
• Who built it and what they know that is not written down. The author has institutional knowledge nobody else has. Capture it before they leave or move teams.
• What the team using it trusts and what they work around. The trust and the workarounds map directly to what the rebuild needs to handle.

That inventory is the basis for the engineering work that needs to come next.

From there, the order is:

1. Preserve the spec. Document what the prototype does and why. The working tool itself is the spec. The documentation reflects what the team actually uses today, which may have drifted from what the original author first imagined.
2. Rebuild the parts that need to be production-grade. Auth, data layer, integration, audit trails, monitoring. These get built once, deliberately, with engineering oversight. The team using the tool should see the same workflow they were using before. The infrastructure underneath gets replaced.
3. Keep the institutional knowledge. The author of the prototype knows things about how the operation works that did not make it into the system. Capture that in the rebuild, or you will lose it when they leave.
4. Decide what to do with new builds. Once the operation is on a stable foundation, future prototypes can keep coming in. The decision is which ones graduate to production and which ones stay as scratch space.

The order matters. 

Skipping any step loses something specific: the spec, the protection, or the institutional knowledge. 

None of those come back easily once they are gone.

‍

What this looks like in practice

Bignition came to us with a commercial insurance platform that the independent agencies using it had outgrown.

The functionality was there, but the platform lacked the workflow structure agents needed to run their day. Agents were working without a clear picture of their pipeline, their relationships, or their progress against growth goals.

The discipline was the same one a prototype rebuild calls for.

We kept what was working, including the AMS360 agency management compatibility the agencies depended on, and built the structure that was missing: an overhauled dashboard, a game plan wizard for goal tracking, referral process flows, new business revenue scenarios, policies and commission screens, and carrier data import.

The agents kept the platform they recognized and gained the structured, actionable view of their business development they had been missing.

We believe that business is built on transparency and trust, and that good software is built the same way.

The trust the agencies had with the parts of the platform they relied on was the asset worth protecting in the rebuild.

The structure they did not have was the work that made the rebuild worth doing.

‍

How to govern this going forward

The pattern of prototypes becoming production by accident does not stop because leadership decides to be more careful. 

It stops when the company puts a small amount of process around AI-built tools that does not slow the team down. 

The four practices below catch the dependency before it becomes critical and leave the building itself untouched:

• Tag every internal tool with an owner and a status. Prototype, in production, or graduated. The labeling alone surfaces what is running in the operation.
• Require any tool that touches customer data or money to go through engineering review before adoption. This is the smallest governance step that prevents the worst exposure.
• Set a review cadence for every prototype. Quarterly, the prototype either graduates to production with the engineering work done, gets retired, or stays a prototype with the dependency made explicit.
• Make the engineering team an advisor on new tools. The goal is faster decisions about which prototypes deserve production-grade work, with the engineering layer brought in early.

The teams that put these practices in place keep the speed of AI-assisted building and remove the worst exposure of running on it accidentally.

‍

Where to start

You probably have one or two of these running in your operation right now. They are easy to spot once you go looking. The signs:

• A tool that is not on any architecture diagram but is used every day
• A runbook that tells someone to "ask Sarah to update the X system" because Sarah is the only one who can
• A function the business depends on that lives on someone's personal laptop or in a personal account
• A tool whose original author has moved teams or left the company, and the team is still using it
• A workflow that breaks if one specific person is out for a week

If you find one, do not panic. 

Prototypes-that-became-production can usually be stabilized in weeks once the engineering team gets involved. 

The expensive version is the one that breaks in front of a customer before anyone got around to looking at it.

If your operation has more than two of these, the next platform investment belongs at the engineering layer underneath what your team already built. 

Adding another tool alongside will just create the next dependency without ownership.