Over the last six months, building a prototype of almost anything in software became a weekend project. I’ve watched it happen and I’ve been in the room when the decision to keep building gets made.
This piece is about the cost that arrives after the demo: the decision to build what you should have bought, made on a cost model with its largest item missing.
Hi btw, I’m Martin and I’m the CTO at Flank.
The room always nods at the prototype
I have been in a lot of conversations recently with founders, business leaders, and tech leads who are seriously considering building software in-house that, twelve months ago, they would have bought without hesitation. The reasoning is almost always the same. Coding agents got dramatically better in the last six months. A senior engineer with Claude Code or Cursor can stand up a functional prototype of almost anything in a weekend. The internal demo lands. The room nods. The decision feels obvious.
I want to make the case that, for most lean organisations, this decision is being made on the basis of a cost model that is missing its largest line item.
🏗️ The cost the prototype hides
The prototype is real. That is what makes the temptation difficult to argue with. The thing works. Someone built it in a few days. It cost almost nothing. From there, the build-it-yourself argument writes itself: why pay a vendor when we can ship a version of this internally for less than the first month of their contract?
The error is in treating the prototype as the product. The prototype is the easy part of the cost curve. The expensive part begins after the demo, and it shows up as four separate costs that almost never get priced together.
The prototype is the easy part of the cost curve. The expensive part begins after the demo.
The first is the rest of the build. A POC is a feature. A product is the long tail of edge cases, configurations, error states, and “what happens when this user does that” questions that nobody thought about when the demo was built. The second is the ongoing build, because the thing you launched at version one is not the thing your team needs at version five, and you will be writing that delta yourselves now. The third is integration: making the new system speak to the systems that already exist, including the ones whose APIs nobody on your team enjoys reading. Owning the build does make this slightly easier than integrating with a vendor, but it does not eliminate the cost. The fourth is maintenance.
I want to spend most of this piece on the fourth, because in my experience it is the one that is most chronically underestimated, and the one that most reliably eats lean organisations alive.
Maintenance is not a money problem
When people price maintenance, they tend to price the obvious things. An engineer’s time. A bit of cloud spend. A Slack channel for incidents. These costs are real, but they are not the ones that matter. The cost that matters is the one that is hardest to put on a spreadsheet, which is what the maintenance burden does to the focus and velocity of the team that is supposed to be building your actual product.
If you are running a lean organisation, you have one thing you are known for. One product or service that customers come to you for. That thing is your unfair advantage and it is also your most fragile resource, because the moment your team starts spending its attention on something other than that, the rate at which the core product improves slows down. Not by a small amount. By a structural one.
Maintaining internal software is not a side project. It is a permanent claim on the most expensive resource in your company, which is the focus of your senior engineers and the prioritisation cycles of your leadership team. Every internal tool you maintain is a system that will, periodically, go wrong in ways that interrupt whatever your team was supposed to be doing. Every internal tool generates its own roadmap of feature requests from internal users who reasonably expect to be served. Every internal tool eventually requires someone to make a decision about whether to invest in it further or let it decay, and that decision is itself a tax on leadership attention.
Maintaining internal software is not a side project. It is a permanent claim on the most expensive resource in your company.
This is the cost almost nobody puts on the page when they make the build decision. It does not appear in the prototype’s budget. It appears six months later as a slower release cadence on the product that pays the bills.
⚡ The distraction tax compounds
What I keep seeing in start-ups and lean teams is a pattern I think of as the distraction tax. It is not a single line item. It is a slow leak across several of them.
Leadership has to think about the internal build. Even when they delegate it, it still consumes prioritisation cycles, because every quarter someone has to decide whether the internal tool needs more investment or less, whether to roll a security patch or defer it, whether to expand its scope to the next team or freeze it. These decisions are not free. They displace decisions about the core product.
Engineers have to context-switch onto it. The same engineer who could have been shipping the next major feature on your core product is now debugging the document parser, the auth flow, or the integration with whatever third-party system the internal tool depends on. The cost is not the hour they spent fixing it. The cost is the half-day of deep work they were no longer available for.
The shipping cadence slows. Slowly, then all at once. Six months in, you notice that you used to ship a meaningful improvement to your core product every two weeks and now it is closer to every six. The internal tools you built to “save time” turned out to have an interest rate, and you have been paying it ever since.
I do not think any of this is controversial when stated this way. The reason it keeps happening is that the costs are diffuse and the prototype’s win is concentrated. The demo is on Tuesday. The slowdown becomes visible in Q3.
The demo is on Tuesday. The slowdown becomes visible in Q3.
🧠 The vendor’s unfair advantage is focus
There is a corresponding fact about the company you would be buying from, which I think gets short shrift in build-versus-buy conversations.
A vendor that does one thing has focus as a structural advantage that is genuinely hard to replicate. The whole company is paying attention to that one problem. Their engineers wake up thinking about edge cases that you have not yet imagined. Their roadmap is informed by the experience of every other customer who ran into the issue you are about to run into. Their support team has seen your bug before. Their security posture has been scrutinised by procurement teams more paranoid than yours. None of this is something you can buy with engineering hours. It is the consequence of the entire organisation being pointed at one problem for years.
When you build a version of that capability internally, you are competing against this. Not on the day of the demo, where the gap can look small. Over the lifetime of the system, where the gap compounds. The vendor’s product gets meaningfully better every month because it has to. Yours gets meaningfully better when you can spare the cycles, which is rarely, because the team is supposed to be working on the thing that makes you money.
I think this is the part of the decision that is most under-modelled. The build-it-yourself argument tends to treat the vendor and the internal build as roughly equivalent capabilities, with the only difference being who pays for the engineering. That is not how the comparison actually plays out. You are not comparing two engineering teams of equivalent intent. You are comparing a team that has this problem as a side concern with a team that has it as the entire reason for their existence. Focus is the asymmetry, and over a few years it produces a quality and velocity gap that is very difficult to close.
You are not comparing two engineering teams of equivalent intent. You are comparing a team that has this problem as a side concern with a team that has it as the entire reason for their existence.
“But it doesn’t do exactly what we need”
The most common objection at this point is that the bought product does not do exactly what the internal team needs. There are missing features, missing configurations, missing integrations. The argument is that the only way to get the precise capability is to build it.
I find this objection less compelling than it first appears, for two reasons.
The first is that “exactly what we need” is usually less specific than the team thinks. When you actually decompose the requirement, most of what makes it feel bespoke is the surrounding workflow, not the underlying capability. The right architectural move there is to build the thin layer of specificity yourself, the abstraction that wraps the bought capability in your team’s particular workflow, while letting the vendor own the underlying machinery. You keep the parts that are genuinely yours and offload the parts that are not.
The second is that the missing feature, the one that today looks like a deal-breaker, is very often already on the vendor’s roadmap, or can be moved onto it. If you tell a focused vendor that this capability is the one thing standing between them and a deal, the odds that they ship it faster and better than you would have built it are high. They have the team, the architecture, and the test coverage. You have a Friday afternoon. The “build it because the vendor does not have feature X” argument quietly assumes that the vendor will not respond to your request, which in my experience underestimates how quickly a focused team can ship something they have already been thinking about.
The deeper point is that nearly every feature you want to build internally is, somewhere in the world, already someone’s day job. The question is not whether you can build it. With current coding agents, you almost certainly can. The question is whether the version you build, and then maintain, and then keep up to date, will end up better or worse than the version produced by people whose entire professional existence is organised around making it as good as possible. For commodity capabilities, the answer is almost always worse, and the gap widens with time.
A working principle for lean teams
I find the cleanest way to think about this is to ask, for any given capability, whether your team is going to make it meaningfully better than a focused vendor would. Not whether you can match them at version one. Whether you can keep matching them at version five, while also shipping the product your customers actually pay you for.
If the answer is no, build the abstraction that lets you swap providers later, buy the capability today, and put your engineering hours into the thing that is genuinely yours. If the answer is yes, you are probably looking at your core product, and you should not have been considering buying it in the first place.
The trap that current coding agents create is that they collapse the distance between idea and prototype, which makes everything look buildable. Almost everything is buildable now. That is not the same as it being worth building. The constraint that matters has not changed. It is the focus of the team, the cadence on the core product, and the institutional attention that gets diverted every time you take on a system you did not need to own.
A useful rule, I think, is to build only the things that, if you got them right, would still feel like yours in five years. Build the products and capabilities that are inseparable from why your customers come to you. Buy almost everything else, including the things your engineers could absolutely build over a weekend with an agent. Especially those, in fact. The weekend prototype is not the cost. The eighteen-month maintenance debt is, and it is paid in the slowest and most expensive currency you have, which is your team’s attention to the work that is actually yours to do.
✳️
Martin Lukac is the CTO at Flank, where he builds agentic legal services infrastructure for enterprise in-house teams.
