Every internal system — an expense approval portal, a reporting warehouse, a shared authentication layer, an order tracking tool — starts with the same meeting. One person argues for building it because the requirements are too specific. Another argues for buying because it is faster. A third, usually the person carrying the pager, points out that the real question is not who writes it but who runs it for the next five years. All three are right, and the meeting usually ends with whoever argued most convincingly rather than with an analysis.

This article proposes four axes that separate the decision from the argument: strategic differentiation, total operational load, integration depth, and exit cost. They deliberately do not combine into a single score. They give you four independent answers, and when those answers contradict each other, the contradiction is the most useful thing you have learned.

What the three options actually mean

Build means your team writes the code, owns the code, and owns the whole lifecycle: architecture, testing, releases, monitoring, security patching, dependency upgrades, and the two-in-the-morning incident. Building does not end at go-live. That is when the expensive part starts.
Buy means you pay for something that already exists, accept its data model and its opinions about your process, and in exchange stop maintaining the core. You still configure it, integrate it, manage permissions, train users and manage the vendor relationship — the part most often left out of the comparison.
Managed service means the software or infrastructure may still be yours, but day-to-day operational responsibility sits with someone else under a service commitment. You keep the architectural decisions and the data. You transfer the repetitive work, the rotation and the incident response.

These are not mutually exclusive. A system can be bought at the core, built at a thin integration layer, and managed at the infrastructure tier underneath. In organisations that have been through a few investment cycles, that mixture is the most common shape.

Axis 1: does this create competitive differentiation?

The question is not whether the system is important. Payroll is important, but no customer chooses you because your payroll is better than a competitor’s. The right question is: if this system were merely average for your industry, would the business lose anything?

A blunt test: imagine your closest competitor buys exactly the product you are considering and configures it identically. If that does not bother you, this is not a system to build. If it genuinely costs you something — how you price, how you route orders, how you score credit risk, a workflow customers can feel — then it is a legitimate candidate for building.

Most internal systems fail this test. That does not make them trivial. It means their value lies in working reliably, not in being different.

Axis 2: total operational load, not build cost

The most common mistake is putting a one-time development estimate next to an annual subscription. Those are not the same kind of number. Build cost is an event. Operational load is a flow that lasts exactly as long as the system does.

Estimate each of the following in person-hours per month rather than in currency, because person-hours are the thing your team genuinely cannot conjure more of:

Monitoring, alerting, and triaging false alarms.
Security patching for the operating system, dependencies and runtime — including the unplanned emergency ones.
Major version upgrades, which always cost more than estimated because they drag regression testing with them.
Backups, real restore tests rather than confirmations that a backup file exists, and disaster rehearsals.
Access management: granting, revoking when people leave, and periodic review.
Out-of-hours coverage and incident response.
Answering internal user questions, which never appears in the original estimate.

Added up, many teams discover that a system they built consumes most of their engineering capacity simply to stand still. That is a real cost, and it competes directly with work that generates revenue.

Axis 3: integration depth

Integration depth measures how much this system must know about the rest of your business. A standalone tool that receives a nightly CSV is shallow. A system that reads and writes your primary operational database, shares login sessions, honours internal authorisation rules and reacts to events in real time is very deep.

Depth pushes the decision in two opposite directions at once, which is where organisations get stuck. It pushes toward building, because off-the-shelf products rarely match a bespoke data model. It also raises exit cost sharply on the fourth axis, because every integration point is a wire someone has to cut later.

A pragmatic way out: keep the depth in a layer you control. Buy or manage the core, then build a thin translation layer between the vendor’s data model and yours. That layer is code you own, it is small, it is easy to test, and it is the piece you keep when you change vendors.

Axis 4: exit cost

This axis is almost always skipped at decision time and always remembered at the worst possible moment. Exit cost is the effort required to undo today’s choice, measured in elapsed time, disruption risk, and the number of other systems that must change with it.

Ask four questions before you sign anything or write the first line of code:

In what format does the data leave, and who holds the documentation for that format?
How many other systems would need changes if this one disappeared?
Where does the operational knowledge live — in documentation, in the code, or in two people’s heads?
If the vendor raised the price sharply or discontinued the product, how long would a replacement take?

Note that building does not automatically produce a low exit cost. An undocumented in-house system understood by one person and built on an unmaintained library is far harder to leave than a commercial product with a clear data export API.

The four axes side by side

Axis	Leans build when	Leans buy when	Leans managed when
Differentiation	Your specific approach is something customers feel	This is a standard industry capability	The differentiation is reliability, not features
Operational load	Your team has spare capacity and the load is light	The load transfers to a software provider	Load is heavy, continuous, and needs out-of-hours cover
Integration depth	Very deep and bespoke; nothing off the shelf fits	Shallow; batch exchange is enough	Deep at the infrastructure tier, standard at the application tier
Exit cost	You accept the cost to keep full control	Data exports cleanly and boundaries are clear	The contract contains handover and data return terms

Why build decisions rarely survive year two

This is the most honest part of the framework. The repeated pattern is that a decision to build is seldom wrong in year one and very often wrong in year two. The reasons are not technical.

In year one the system has an enthusiastic owner, its own budget, leadership attention, and code new enough to carry no debt. In year two the owner has moved to another project or left, the budget has been folded into general operating costs, leadership attention has moved on, and dependencies start demanding upgrades. The system does not break. It slowly becomes the thing nobody wants to touch.

The arguments used to justify building rarely hold either:

Our requirements are too specific. Usually a small slice of the requirements is genuinely specific and the rest is habit. Isolate that slice and ask whether it justifies building everything around it.
Building is cheaper. True when comparing development cost with subscription fees, false once you add axis two across the whole lifecycle.
We want control. Control is real, but control without anyone maintaining it is just liability.
The team will learn a lot. They will. The business has to ask whether that lesson is in a field it wants to be good at.

A simple test: write down the name of the specific person who will own this system in month twenty-four, then ask that person now. If nobody can answer, the build decision has not been made — it has been deferred.

When the right answer is to keep it in-house

This framework does not conclude that you should outsource. There are cases where keeping everything in-house is correct, and they deserve to be stated plainly.

The system touches core competitive differentiation and you need a rate of change no contract will match.
Your team already has genuine operational capability, a sustainable rotation, and this system will not break it.
Regulatory or internal policy constraints mean granting a third party access creates more risk than it removes.
Your scale is large enough that the unit cost of running it yourself is clearly lower, and you have enough people to keep that true when a few of them leave.

If three of those four describe you, keep it in-house and invest in documentation and process rather than shopping for a vendor. An outsourcing decision taken only to avoid building internal capability tends to return later as a contract that is hard to leave.

Running the decision in two weeks

A framework is only useful if it terminates. A compact approach: in week one, write a single page for each axis, each with a named owner. In week two, hold one meeting to read all four pages together, record where they disagree, and choose. If four pages are not enough to decide, the problem is that the system’s scope is unclear, not that you lack data.

Record the decision with a review date, typically twelve to eighteen months out. At that review the question is not whether you were wrong, but which assumptions changed. Scale, team and market context all move, and a decision that was right in year one can legitimately need reversing in year three.

How HiTechCloud can help

HiTechCloud provides software development and managed infrastructure services, is an AWS partner and a Google Premier Partner, and operates in-country infrastructure for customers with data location requirements. If you are in the middle of a build, buy or manage decision, we can work through the four axes with your team, estimate the realistic operational load of the build option, and say clearly which parts belong in-house. In plenty of cases the reasonable conclusion is that you run it yourself and we help with a narrow slice, or not at all — and that is a conclusion we are willing to state.