Nobody promotes a prototype to production. The users do it for you.
In this guide
- Why Success Is the Trap
- What Actually Makes Something a System of Record?
- How Do You Know You Have Crossed the Line?
- Why Don’t Obligations Scale in a Straight Line?
- Shadow IT With a Better Interface
- Graduate, Retire, or Replace: Deciding on Purpose
- The One Choice That Does Not Work
- Frequently Asked Questions
Why Success Is the Trap
A prototype becomes a system of record when people start depending on its data, not when anyone decides it should. Failed prototypes cost nothing, because they get abandoned. Successful ones create permanent obligations, and the organization usually notices only after the obligations have already arrived.
A team at one global enterprise technology company built a strategy tracking app with AI-assisted coding. It was good. It solved a real problem that their previous process had not. Word spread, other teams asked for access, and within months around five hundred people were using it to set goals, track progress, and prepare for business reviews.
By any reasonable measure, the project had succeeded. That success is exactly what forced the next question. The company now had to decide whether to hire two engineers to maintain and extend the app permanently, or to move to a specialist platform. The prototype had become something else, and nobody could say quite when.
Failed prototypes are easy. They get abandoned, and the cost stops. Successful prototypes are the ones that create long-term obligations, because people start to depend on them.
This is counterintuitive. The usual worry about AI-built tools is that they will not work well enough. In practice, the bigger risk is that they work well enough to be adopted, but not well enough to be relied on. The gap between those two states is where most of the cost of ownership lives.
What Actually Makes Something a System of Record?
Nobody designs a prototype to be a system of record. It becomes one when the organization starts treating its data as the official version of the truth. The moment a leadership team opens it to prepare a quarterly review, or a manager uses it to support a performance conversation, the app has changed category, regardless of how it was built or what it was meant to be.
Intent does not matter here. What matters is what happens if the app disappears tomorrow. If the answer is that a team would need to rebuild its planning process, the prototype is already a system of record, whether or not anyone has called it one.
How Do You Know You Have Crossed the Line?
There are a few reliable signals. Other teams have built processes around the app, such as a planning cadence or a review template that assumes it exists. Its data is used to make decisions about budgets, priorities, or people. Users have started asking for access controls, because some goals are sensitive and not everyone should see everything. And outages now produce escalations rather than shrugs.
Any one of these means the organization depends on the app. All four together mean it has quietly become infrastructure.
Compare Two Engineers Against a Platform
Why Don’t Obligations Scale in a Straight Line?
Fifty enthusiastic users in one department will tolerate a lot. They know the person who built the app, they can ask for fixes in person, and they forgive the rough edges. Five hundred users across several functions behave differently. They expect the app to be available, secure, and consistent. They need onboarding. They have different permissions requirements, different reporting needs, and different managers who all have opinions.
Each step up in adoption adds obligations faster than it adds users. Single sign-on, automatic provisioning and removal of leavers, audit history, data retention rules, integration with the HR system: none of these matter at fifty users, and all of them matter at five hundred. The app’s builder is now running an enterprise platform with a prototype’s foundations.
Fifty Users Versus Five Hundred
| Requirement | At fifty users in one department | At five hundred across functions |
|---|---|---|
| Availability | Tolerated when it breaks. People know who to ask | Expected. An outage produces escalations |
| Access control | Everyone sees everything, and that is fine | Sensitive goals need permissions that differ by function |
| Onboarding | The builder explains it in person | New joiners arrive continuously and need materials |
| Single sign-on | Does not matter | Required, along with automatic provisioning and removal of leavers |
| Audit history | Nobody asks | Needed, because the data now supports decisions about people and budgets |
| Data retention | No policy exists | Rules apply, and someone has to be accountable for them |
| Integrations | None. Data is entered by hand | HR system integration, or the records drift out of date |
| Reporting | One team’s view is enough | Several functions need different cuts, and their managers all have opinions |
Read down the right-hand column and you are reading a specification for enterprise software. None of it was in the original prompt, and none of it was in scope when the app was built over a few evenings. The work of holding this kind of boundary, including where data is allowed to live, is set out on the Profit.co data security page.
What Profit.co Already Carries at Five Hundred Users
Most of that right-hand column is work Profit.co has already built and keeps running. A team that replaces the prototype inherits it on the first day instead of building it over the next two years.
| Requirement at five hundred users | What Profit.co provides |
|---|---|
| Access control | Role-based access limits sensitive goals to the people who should see them |
| Single sign-on | Sign-in through identity providers such as Okta and Azure AD |
| Onboarding | A guided onboarding team, OKR coaching and an OKR Certification program bring new joiners up to speed |
| Data retention | Customer business data is removed, including from rolling backups, once a contract ends |
| Integrations | Connectors to 100+ tools keep goal data current without anyone re-entering it |
| Reporting | Live dashboards give each function its own view, and stakeholder summaries generate from goal data in one click |
| Security | SOC 2 Type II and ISO 27001 certifications, with every connection encrypted |
Shadow IT With a Better Interface
IT and security teams have spent years managing shadow IT, the spreadsheets and unsanctioned tools that grow up outside official systems. Vibe-coded apps are the next generation of the same thing, with one important difference: they look and feel like real software. That makes them more likely to be adopted, and less likely to be scrutinized.
A spreadsheet that holds the company’s strategic priorities is obviously fragile, so people treat it carefully. A polished app holding the same data looks trustworthy, so people trust it, even when nobody has reviewed how it stores data, who can access it, or what happens if its builder leaves.
This is the same governance gap that IT portfolio management exists to close, arriving through a door that no portfolio review is currently watching.
Graduate, Retire, or Replace: Deciding on Purpose
Once a prototype has become a system of record, there are only three honest choices. You can graduate it: fund it properly with dedicated people, a security review, a roadmap, and an owner who is accountable for it. You can retire it, accepting the disruption. Or you can replace it with a platform built for the job, carrying forward what the prototype taught you.
The Three Honest Choices
| Choice | What it actually commits you to | When it is the right answer |
|---|---|---|
| Graduate | Dedicated people, a security review, a roadmap, and a named owner accountable for it | The problem is genuinely specific to you, and you are willing to be in the software business for it |
| Retire | Accepting the disruption to everyone who now depends on it | The app proved the need was smaller than it looked, or the process it supports is changing anyway |
| Replace | Moving to a platform built for the job, carrying forward what the prototype taught you | The problem is shared by many organizations, and the system has to keep growing as the world changes |
The enterprise in our example chose replacement, and its reasoning is worth repeating. The people involved valued working with a company that specialized in this problem and had learned from hundreds of customers, because the platform would need to keep growing as the world changed. The prototype had done its job. It had proved the demand and shown what mattered.
If replacement is the direction, the evaluation criteria are worth writing down before you start looking, which is the subject of this OKR tools features checklist.
The One Choice That Does Not Work
The one choice that does not work is the default: letting the prototype carry on as infrastructure while still being treated as an experiment. That is where costs accumulate, risks go unexamined, and the organization ends up depending on something no one is responsible for.
The next question is what the prototype’s builders were never asked to provide: the requirements that only show up once real people rely on the system.
Key Takeaways
- →Failed prototypes cost nothing because they get abandoned. Successful ones create permanent obligations, which makes success the risk rather than failure.
- →A system of record is defined by dependence, not intent. The test is what breaks if the app disappears tomorrow.
- →Four signals mean you have crossed the line: other teams build processes around it, its data drives decisions, users ask for access controls, and outages produce escalations.
- →Obligations grow faster than users. SSO, provisioning, audit history, retention and HR integration matter at five hundred users and not at fifty.
- →Graduate, retire or replace. The one choice that fails is the default: running it as infrastructure while still calling it an experiment.
See What a Platform Built for This Looks Like
Frequently Asked Questions
A system whose data the organization treats as the official version of the truth. It is defined by dependence, not by design intent. If a team would have to rebuild its planning process when the app disappeared, that app is already a system of record.
Four signals: other teams have built processes around it, its data is used to decide budgets, priorities or people, users have started asking for access controls, and outages now produce escalations rather than shrugs. Any one means dependence. All four mean infrastructure.
A failed prototype gets abandoned and the cost stops. A successful one gets adopted, and people depend on it. The real risk is an app that works well enough to be adopted but not well enough to be relied on, which is where most ownership cost lives.
Yes, with one difference that makes them harder to govern: they look and feel like real software. A fragile spreadsheet gets treated carefully. A polished app holding the same data looks trustworthy, so it gets trusted without anyone reviewing storage, access or succession.
Graduate it with dedicated people, a security review, a roadmap and a named owner. Retire it and accept the disruption. Or replace it with a platform built for the job. The default, running it as infrastructure while calling it an experiment, is the only option that fails.
