A vendor’s price includes almost everything needed to run the platform. A salary includes almost none of it.
In this guide
- Total Cost of Ownership Beyond Salaries
- Engineers Need Management, and Management Is Not Free
- The Infrastructure Bill Grows With Use
- Security and Compliance Are Recurring, Not One-Off
- Two People Cannot Provide Continuous Coverage
- Turnover Is a Cost You Will Pay Eventually
- The Largest Cost Does Not Appear on Any Budget
- How to Calculate Build vs Buy TCO
- Frequently Asked Questions
Key Takeaways
- →The two sides are not measured the same way. A subscription covers nearly everything needed to run a platform; a salary covers nearly none of it.
- →Infrastructure and tooling are underestimated because they arrive as many small invoices across different budgets rather than one line.
- →Security and compliance recur. Reviews repeat, regulations change, and new vulnerabilities appear in libraries the app depends on.
- →Two people cannot cover holidays, illness and training. Covering it properly means accepting risk or adding headcount, which changes the calculation.
- →Opportunity cost never appears on a budget and is often larger than every other line combined. Run the comparison over three to five years, not one.
Total Cost of Ownership Beyond Salaries
Total cost of ownership is the full cost of running a system over its life, not the price of creating it. For internally built software the visible figure is salaries, which excludes employment overheads, management, infrastructure, compliance, coverage, turnover and opportunity cost.
When an organization compares building with buying, the build side of the comparison is usually short. Two engineers, two salaries, perhaps some cloud hosting. The vendor side has a subscription price, an implementation fee, and a contract term. Set side by side, the internal option often looks cheaper, especially once AI tools have shortened development time.
The comparison is misleading because the two sides are not measured the same way. The vendor’s price includes almost everything needed to run the platform. The salary figure includes almost none of it. To compare fairly, the build side needs the same treatment: every cost of owning the system, not just the most visible one.
The cost of employing someone is always more than their salary. Employers pay benefits, payroll taxes or social contributions, equipment, software licenses, office space or remote-work allowances, and training. The exact multiple varies widely by country and company, but the fully loaded cost of an engineer is meaningfully higher than the number on the offer letter.
Then there is the cost of getting them in the first place. Recruiting experienced engineers takes time and money, whether through internal recruiters, agencies, or the hours of interviewing that existing staff give up. A new hire also needs weeks or months to become fully productive, during which the organization pays full cost for partial output.
Engineers Need Management, and Management Is Not Free
Two engineers do not manage themselves. Someone sets priorities, reviews their work, handles performance conversations, approves leave, and resolves conflicts between competing requests. That someone is usually an engineering manager or a senior leader whose time is already committed elsewhere.
There is also the product work discussed in >an earlier article: deciding what the app should become, which requests to accept, and how it should evolve. If no one is hired to do it, it falls on a manager who is not trained for it or it does not happen at all. Either way, it is a cost, paid in time or in the quality of the result.
The Infrastructure Bill Grows With Use
A prototype often runs on modest infrastructure. A system used by hundreds or thousands of people needs more: production hosting with redundancy, separate environments for development and testing, backups, monitoring, logging, and the tools engineers use to build and deploy safely.
Each of these carries a subscription or usage cost, and each grows as adoption grows. They are easy to underestimate because they arrive as many small invoices, often charged to different budgets, rather than as one clear line.
There is also the tooling that surrounds the engineers themselves. AI coding assistants, source control, testing services, error tracking, and security scanners each carry their own license. Individually they are modest. Together, and multiplied across the life of the system, they become a real number, and one that rarely appears when the build decision is first made.
Security and Compliance Are Recurring, Not One-Off
Once an internal app holds sensitive strategy and performance data, it attracts the attention of security and compliance teams, as it should. That means security reviews, vulnerability scanning, possibly penetration testing, and answers to internal and external questionnaires. In regulated industries or multi-region organizations, it may mean formal assessments against data protection requirements.
None of this happens once. Reviews recur. Regulations change. New vulnerabilities are discovered in the libraries the app depends on. A vendor spreads these costs across its whole customer base. An internal team carries them alone, usually by taking time from development.
Put a Number on the Build Side
Two People Cannot Provide Continuous Coverage
Two engineers sounds like a team, but in practice it is a fragile one. People take holidays, fall ill, attend training, and have family commitments. When one is away, the other carries everything alone. When both are away, nobody does.
For a system that the organization relies on, especially during planning periods and quarterly reviews, that gap matters. Covering it properly means either accepting risk or adding people, and adding people changes the cost calculation considerably.
Turnover Is a Cost You Will Pay Eventually
Engineers change jobs. When one of the two leaves, the organization pays to recruit a replacement, loses productivity during the vacancy, and pays again while the new person learns a codebase they did not write. The departing engineer’s knowledge of why things were built the way they were often leaves with them.
Turnover is not a remote possibility to be ignored in a budget. Over a multi-year horizon, it is very likely, and an honest cost model should include it.
The Largest Cost Does Not Appear on Any Budget
The most significant cost is the one that is easiest to overlook: what those engineers would otherwise be doing. Every organization has more valuable work than engineering capacity. Engineers assigned to maintain an internal strategy app are not improving the products customers pay for, automating core operations, or building the capabilities that set the business apart.
This opportunity cost will never appear in a budget, but it is real, and it is often larger than all the other costs combined. It is also the cost that leaders care most about once they see it clearly.
Consider what two experienced engineers could achieve in a year if they were working on the organization’s core products instead. A new capability for customers, a faster release cycle, an automated process that saves hundreds of hours. Set against that, an internal goal-tracking app is a costly use of scarce talent, even if the app itself works well.
How to Calculate Build vs Buy TCO
A fair comparison sets the full cost of building against the full cost of buying. The table below is the checklist. It carries no figures deliberately, because employment multiples, infrastructure rates and salary levels vary widely by country and company. Fill it in with your own numbers and the comparison becomes honest.
The Build vs Buy TCO Checklist
| Cost line | On the build side | On the buy side |
|---|---|---|
| Fully loaded employment | Salary plus benefits, payroll taxes or social contributions, equipment, software licenses, workspace or remote allowance, training | Carried by the vendor, inside the subscription |
| Recruiting and onboarding | Recruiter or agency fees, interview hours given up by existing staff, weeks or months of full cost for partial output | None |
| Management time | Setting priorities, reviewing work, performance conversations, approving leave, resolving competing requests | None |
| Product ownership | Deciding what the app becomes, which requests to accept, how it evolves. Paid in time or in the quality of the result | Carried by the vendor |
| Infrastructure | Production hosting with redundancy, development and test environments, backups, monitoring, logging, build and deploy tooling. Grows with adoption | Inside the subscription |
| Engineering tooling | AI coding assistants, source control, testing services, error tracking, security scanners, each with its own license | Inside the subscription |
| Security and compliance | Recurring reviews, vulnerability scanning, penetration testing, questionnaires, data protection assessments. Recurs every year | Spread across the vendor’s whole customer base |
| Absence coverage | Two people cannot cover holidays, illness, training and family commitments. Either accept the risk or add headcount | Inside the subscription |
| Turnover | Recruiting again, lost productivity during the vacancy, ramp-up on a codebase nobody wrote, knowledge that leaves with the person | None |
| Opportunity cost | What those engineers would otherwise have built. Never appears on a budget and is often larger than everything above combined | None |
| Subscription | None | The visible price, usually per user per period |
| Implementation | None | A one-off fee, plus internal time during rollout |
| Internal administration | Already counted under management above | Someone configures and administers the platform |
| Integration work | Counted under engineering above | Connecting to HR, project and finance systems |
Two rules make the result trustworthy. Run it over three to five years rather than one, because the build costs grow as the system grows while a subscription is more predictable. And fill in both columns honestly: the buy side has real costs in the last four rows, and a comparison that pretends otherwise is as misleading as the one that counted only salaries.
Many organizations that do this exercise carefully find that the two salaries they started with were a small part of the real number.
None of this means building is never worth it. It means the decision should be made with the full cost in view. Vibe coding has made the first version cheaper than ever. It has done much less for the cost of owning that version for years.
The people behind an internal app are also its biggest single risk. The next article looks at what happens when one of them leaves.
Compare the Full Cost, Not the Visible One
Frequently Asked Questions
The full cost of running a system over its life rather than the price of creating it. For an internal build that means employment overheads, recruiting, management, infrastructure, tooling, recurring compliance, absence coverage, turnover and opportunity cost, not just salaries.
Put both sides through the same checklist over three to five years. On the build side count fully loaded employment, recruiting, management, product ownership, infrastructure, tooling, compliance, coverage, turnover and opportunity cost. On the buy side count subscription, implementation, administration and integration work.
Employers also pay benefits, payroll taxes or social contributions, equipment, software licenses, workspace or remote allowances, and training. The multiple varies widely by country and company, so use your own finance team’s figure rather than a published rule of thumb.
Opportunity cost. Engineers maintaining an internal strategy app are not improving the products customers pay for or building what sets the business apart. It never appears on a budget, it is often larger than every other line combined, and it is the one leaders react to once they see it.
It is a fragile team. People take holidays, fall ill, attend training and have family commitments, so when one is away the other carries everything. For a system the organization depends on during planning and quarterly reviews, covering that gap means accepting risk or adding headcount.
Three to five years. Over a single year the build side looks favorable because most of its costs have not arrived yet. Build costs grow as the system grows and as turnover and compliance cycles land, while a subscription is more predictable.
