Someone builds a working version over a weekend and shows it round on Monday. It does about 60% of what the tool you were going to pay for does. The room gets a little excited.

Two engineers, six weeks, and you own it. That's the pitch, and the arithmetic in it is correct.

It's also pricing about a fifth of what you're actually buying.

The build was never the expensive part

Maintenance runs 70 to 80% of a system's lifetime cost. Not the build. The keeping it alive.

AI collapsed the build. It did nothing to the other 70%, because that part was never about writing code.

So the six weeks got cheaper and the four years didn't.

What the other 70% is made of

"Maintenance" sounds like occasional tidying, which is why it gets waved through in the meeting.

It's every integration breaking when the system on the other end changes its API. Security patching. The compliance re-audit that comes round on a cycle rather than once. Technical debt piling up in something that is nobody's actual job.

One breakdown puts API upkeep alone at 20 to 35% of the original build cost, annually. That's before anyone adds a feature. That's just staying connected to things that keep moving.

Then the person who built it leaves

This one is in every honest analysis and never in the business case.

Whoever built your internal tool is the only person who fully understands it. When they go, what was an asset becomes a liability nobody can safely touch.

Hiring a replacement mostly doesn't work. Senior engineers avoid internal-tools maintenance roles, because the work is dull and it builds no career, and everyone in that market knows it.

So it doesn't get maintained. It gets tolerated, then worked around, then replaced by the thing you nearly bought four years earlier.

The bill arrives as features that didn't ship

Ask what an internal tool costs and the answer comes back as a salary figure.

The real number is the roadmap. Every sprint on internal tooling is a sprint not on the product people pay you for, and that's the largest hidden cost in the whole decision.

At smaller scale it gets uncomfortable. One analysis puts waste from internal platform work at $500,000 to $1 million a year, and notes it isn't recovered when the effort is eventually shut down.

The same piece gives a threshold that's worth writing down. Under 20 engineers, don't build a platform function. Twenty to thirty, maybe a fraction of someone. Thirty to fifty, watch for friction. Fifty and up, you're already paying the cost of not having one.

Plenty of companies well under that line are actively discussing building.

"But there's a free one"

Different question, not an easier one.

Free covers the licence. It does not cover integration, hardening, or keeping current with releases. Open source tools remain excellent building blocks and are not free, because someone still does all of that.

With a platform team and an unusual requirement, adopting and extending open source is often exactly right. No argument.

With three DevOps engineers and a roadmap, the choice isn't free versus paid. It's a vendor's ongoing engineering versus your own, and yours is already spoken for.

Where this lands for us

I work at Frigga, so this is the decision being made about our own product, and it would be odd to write all of the above and skip it.

What we've built connects to your code, your cloud, your pipelines and your monitoring, and makes that context available to the AI tools your team already uses. Could a strong engineer build a version of that? For one or two of those systems, probably, and reasonably quickly.

The part that doesn't compress is everything after. Each connector needs maintaining as the system behind it changes. Coverage has to keep expanding as your stack does. It has to keep working when a provider changes an API on a Tuesday.

That's the 70 to 80%, and it's ours rather than yours.

I'd rather put it that way than pretend the build is impossible, because your engineers will know that isn't true and it's the wrong argument anyway.

Three questions worth asking

Who maintains it in year two? Name the person. If the honest answer is whoever built it, plus whatever else they're doing, you have a plan for the build and no plan for the system.

What doesn't get built instead? Be specific about the roadmap item. That's the actual price.

Is this the thing your customers buy from you? Build what makes you different. Buy what makes you functional. Almost every regrettable build I hear about broke that rule.

The best argument for building has always been control. That's still a good argument. The one thing that has never been true is that it's cheaper, and AI has made it look truer than ever at exactly the moment it stopped mattering.

Author note

Ayesha Siddiqua, Business Growth Strategist at Frigga Cloud Labs.

What got me reading about this properly was noticing that build-versus-buy arguments almost never disagree about facts. The engineer is right that it can be built. The founder is right that it's a risk. They're just each looking at a different number and assuming the other one has done the same sum.

Once I saw that, the whole debate stopped sounding like a disagreement and started sounding like two correct answers to two different questions.

If you're in the middle of one of these, I'd be interested to hear where you're landing. LinkedIn.

AI Made Building It Look Cheap. The Expensive Part Never Changed.