Vibe coding changed the first two rows of the analysis. The decision lives in the other seven.
In this guide
Key Takeaways
- →Two of nine factors moved toward building. Two others, risk and lock-in, moved further toward buying.
- →The two that moved are the two you experience first. A prototype can be demonstrated; a compliance questionnaire arrives months later.
- →The decision is effectively made by the people who see the first two rows, because the usual approval process is bypassed.
- →Lock-in reversed. Building creates dependence on individuals, one embedded method, and code few people understand.
- →The framework is binary, and the real answer often is not: buy the core system of record, build the edge around it.
The Classic Make vs Buy Criteria
The make versus buy framework weighs speed, upfront cost, total cost of ownership, expertise, roadmap, differentiation, control, risk and lock-in. AI-assisted development moved the first two decisively toward building and left the rest unchanged or worse, which is where the decision actually sits.
Make-versus-buy is one of the oldest decisions in business. Long before software, companies weighed whether to manufacture a component themselves or buy it from a supplier. Economists, notably Oliver Williamson in his work on transaction costs, studied why firms choose to do some things internally and buy others in the market. Procurement teams developed checklists. The framework is mature, tested, and well understood.
Vibe coding seems to have upended it. Suddenly, anyone can build software, and the old argument for buying, that building is slow and expensive, feels obsolete. Look carefully, though, and the framework is intact. What has changed is a small part of it, and the part that changed happens to be the part that is easiest to see.
A careful make-versus-buy analysis for software weighs a familiar set of factors. How quickly can we have something working? What does it cost upfront, and what does it cost to own over its lifetime? Do we have the expertise to do it well? Who will fund its evolution? Is it a source of competitive advantage? How much control and customization do we need? What are the risks, including security, compliance, and dependence on individuals? And how locked in will we be to the choice we make?
Each factor pulls in a direction. Traditionally, speed and upfront cost favored buying, because building took months. Control favored building. Most of the others, including total cost, expertise, roadmap, and risk, tended to favor buying for anything outside a company’s core.
What Vibe Coding Changed
AI-assisted development transformed two of these factors. Time to a first working version collapsed from months to days. Upfront cost fell close to zero. Both now favor building, sometimes overwhelmingly.
These are dramatic changes, and they are real. An organization can now test an idea for internal software at almost no cost, which is genuinely valuable. It can learn what it needs by building something rather than by writing requirements in the abstract.
What It Did Not Change
The remaining factors are largely untouched. Total cost of ownership is still dominated by maintenance, evolution, infrastructure, people, and compliance, not by writing the first version. Domain expertise is still scarce; AI writes code, not judgment about how strategy execution works. The roadmap still has to be funded, and a single organization still funds all of it alone.
Strategic differentiation is unchanged: a goal tracker is no more core because it was built quickly. Some factors became worse for building. Security and key-person risk increased, because generated code may be less well understood and fewer people may truly know how it works. And lock-in, long the main argument for building, now often points the other way, toward dependence on a small team and a bespoke design.
Nine Factors, and Which Two Moved
| Factor | Traditional direction | After vibe coding | Did it move? |
|---|---|---|---|
| Time to a first version | Favored buying. Building took months | Days rather than months | Yes, toward building |
| Upfront cost | Favored buying | Close to zero | Yes, toward building |
| Total cost of ownership | Favored buying | Still dominated by maintenance, evolution, infrastructure, people and compliance | No |
| Domain expertise | Favored buying | Still scarce. AI writes code, not judgment about how strategy execution works | No |
| Roadmap and evolution | Favored buying | One organization still funds all of it alone | No |
| Strategic differentiation | Favored buying outside the core | A goal tracker is no more core for having been built quickly | No |
| Control and customization | Favored building | Largely untouched | No |
| Risk: security, compliance, key person | Favored buying | Worse for building. Generated code may be less well understood, and fewer people truly know how it works | Yes, further toward buying |
| Lock-in | Favored building | Now points toward dependence on a small team and a bespoke design | Yes, reversed toward buying |
Shaded rows are the two that moved in favor of building.
Why It Feels Like Everything Changed
If only two factors moved, why does it feel as though the whole decision has been overturned? Partly because those two factors are experienced first and most vividly. A working prototype after a weekend is exciting. It can be demonstrated, used, and shared. The benefits are immediate and visible.
The costs are the opposite: delayed, scattered, and abstract. Maintenance arrives as a stream of small requests. Compliance arrives as a questionnaire months later. Key-person risk arrives only when someone resigns. People naturally give more weight to what is vivid and immediate than to what is distant and uncertain, and vibe coding puts all of its advantages in the first category and most of its costs in the second.
Each of those delayed costs has its own article in this series: what two engineers actually cost, what happens when one of them leaves, and what a disputed bonus asks of your records.
Put Numbers on the Other Seven Rows
Nobody Is in the Room for the Long-Term Rows
There is also a structural reason. The people who build a vibe-coded app are usually enthusiastic about it and close to its benefits. They are rarely the people who will handle its security reviews, respond to data access requests, explain a disputed bonus calculation, or replace a departed engineer.
In a traditional build decision, those perspectives would be represented because the investment required formal approval. Vibe-coded apps often bypass that process entirely, so the decision is effectively made by the people who see the first two rows and not by those who will live with the rest.
Lock-In, Reconsidered
The lock-in factor deserves special attention because it has always been the strongest objection to buying. Organizations worry about depending on a vendor: its pricing, its priorities, its future.
Those concerns are legitimate, and they should be tested in any evaluation. But building creates its own form of dependence, on specific individuals, on a single strategy method embedded in the data model, and on code few people understand. A vendor with open interfaces, data export, and a commercial interest in keeping customers satisfied is often less of a lock-in risk than an internal team with none of those properties. A later article in this series explores that difference in commitment directly.
How to Run the Analysis Honestly
To use the framework well in the AI era, give each factor its proper weight over a realistic time horizon of three to five years. Credit vibe coding fully for what it does well: fast learning, cheap experimentation, and the ability to discover requirements by building. Then assess the remaining factors as rigorously as you would for any other long-term commitment.
Include the people who will own the consequences, such as security, compliance, HR, and finance, in the decision. Their perspective is exactly what the prototype’s enthusiasm leaves out.
A Third Option: Buy the Core, Build the Edge
The framework also has a gap that the AI era makes visible. It presents the decision as binary, make or buy. In practice, there is now a strong third option: buy a specialist platform for the core system of record, then use AI-assisted development to build extensions, integrations, and team-specific tools around it.
That combination keeps the speed and flexibility that vibe coding offers where they add value, while leaving the long-term burdens of ownership with a specialist. The final articles in this series explore that option in detail, and the position paper sets out the case in full.
Profit.co is designed for that third option. The platform holds the system of record, while Profit.co MCP lets builders connect ChatGPT, Claude, Cursor and other MCP-compatible tools to it. Access runs through Profit.co’s own authentication, so each person only sees the data they are authorized to see, and the data stays in Profit.co’s infrastructure.
The make-versus-buy framework was never really about how fast code can be written. It was about who should own a capability over its lifetime, and at what total cost and risk. Vibe coding has changed the economics of the first version. It has not changed the economics of ownership, and ownership is where the decision is made.
One factor in that framework carries more weight than most buyers realize: who is actually committed to your success over time.
Decide on Ownership, Not on Speed
Frequently Asked Questions
Nine: time to a first working version, upfront cost, total cost of ownership, domain expertise, roadmap and evolution, strategic differentiation, control and customization, risk covering security, compliance and key-person dependence, and lock-in.
Two moved toward building: time to a first version fell from months to days, and upfront cost fell close to zero. Two moved further toward buying: risk, because generated code may be less well understood, and lock-in, which reversed direction entirely.
Because the two factors it changed are the ones experienced first and most vividly. A working prototype can be demonstrated and shared. Maintenance arrives as small requests, compliance as a questionnaire months later, key-person risk only when someone resigns.
It swaps one form for another. Building creates dependence on specific individuals, on a single strategy method embedded in the data model, and on code few people understand. A vendor with open interfaces, data export and a commercial interest in your renewal is often the lesser risk.
Weigh every factor over three to five years rather than one. Credit vibe coding fully for fast learning and cheap experimentation, then assess the rest as rigorously as any long-term commitment. Include security, compliance, HR and finance, whose perspective the prototype’s enthusiasm leaves out.
Yes. Buy a specialist platform for the core system of record, then use AI-assisted development to build extensions, integrations and team-specific tools around it. That keeps the speed where it adds value and leaves the long-term burdens of ownership with a specialist.
