Build vs Buy for Internal Tools

Executive summary

Build vs buy for internal tools is a decision that gets made informally in most companies. Someone has a spreadsheet that has outgrown itself, or an engineer offers to "knock something together," or a vendor demo makes a tool look inexpensive. Months later the company owns software nobody planned to maintain, or pays for a subscription that fits half the job.

The cost that decides this is rarely the first one. Building looks cheap because the build estimate is visible and the maintenance is not. Buying looks cheap because the subscription is visible and the setup, administration, integration, and workarounds are not. A fair comparison puts both on the same three-year basis and includes the people cost on each side.

This guide gives a short framework. First, define the job the tool must do and who uses it. Second, ask whether the tool is a source of competitive difference or a commodity function. Third, compare three-year cost on a common table. Fourth, check the risks that cost does not show: key-person dependency, data and security obligations, integration load, and exit. Fifth, set a review date, because the right answer changes as the company does.

The default for a mid-market company is to buy for commodity functions and build only where the process is distinctive and you can name who will own it. That default is a starting point, not a rule. The tables and checks below tell you when to depart from it.

When to use this

Use this guide when:

• A spreadsheet or a chain of spreadsheets has become a critical process and is breaking.
• An engineer, analyst, or department has proposed building an internal application.
• A vendor tool fits most requirements and the remaining gap is being used as an argument to build.
• A renewal (see the SaaS and vendor renewal calendar) has raised the question of replacing a subscription with something internal.
• An AI-assisted or low-code approach has made building look easy and you want to test that assumption (see the AI use case prioritization framework).
• A system change such as an ERP replacement (see ERP selection for PE portfolio companies) will leave gaps that small tools might fill.

Diagnostic questions

1. What job must the tool do, stated as an outcome with a frequency and a user, not as a feature list?
2. How many people use it, how often, and what happens if it is unavailable for a day?
3. Is the process a source of competitive difference, or does every company in the industry do the same thing?
4. What does the job cost today in hours, errors, and delays, and how do you know?
5. Which data does the tool read and write, and does that data include customer, employee, or financial records with confidentiality obligations?
6. Which systems must it integrate with, and who maintains those integrations?
7. Who would own the tool after launch: a named person, with time allocated, who is not the original builder?
8. What happens to the tool if the builder leaves?
9. Have at least two off-the-shelf options been priced, including setup, administration, and the cost of workarounds for the gaps?
10. What does the vendor agreement say about data export, price changes, and termination? (Counsel reviews this.)
11. What would make you reverse the decision, and when will you check?
12. Is the company's real constraint cost, speed, control, or capacity to maintain?

If you cannot answer questions 1 and 7, you are not ready to choose. Define the job and name the owner first.

Framework: four tests and a cost table

Apply four tests in order. Each can end the discussion.

There are also middle paths that the build-or-buy question hides. A vendor product can be configured to fit, a low-code platform can host a light application, or a vendor can build to your spec. Each has the same ownership and exit questions. Treat them as options in the cost table, not as exceptions.

Step-by-step process

1. Write the job statement. Owner: business owner. Output: one paragraph with the outcome, users, volume, frequency, and the cost of the current method.
2. List must-have requirements. Owner: business owner and process users. Output: no more than ten must-haves, written as outcomes, and a separate list of nice-to-haves that cannot drive the decision.
3. Run the four tests. Owner: CFO and business owner. Output: a written result for each test, with the reason.
4. Find real options. Owner: business owner. Output: at least two buy options and one build or configure option, each with a written quote or estimate.
5. Build the three-year cost table. Owner: FP&A. Output: the table in the template section for each option, with internal hours valued at loaded cost.
6. Test the build estimate. Owner: CFO. Output: a comparison of the estimate to the actual-versus-estimate record on the company's previous internal projects. Where no record exists, add contingency by method (see metrics section) and state it.
7. Assess non-cost risks. Owner: IT or security lead. Output: a short risk table covering data handling, access control, uptime, backup, and integration.
8. Review commercial terms. Owner: counsel. Output: written comments on data export, price change rights, term, termination, and liability for any bought option, and on code ownership for any commissioned build.
9. Decide and write down the triggers. Owner: CFO. Output: a decision memo with the choice, the reasons, the owner, and the review date and conditions that would reverse it.
10. Pilot before commitment. Owner: business owner. Output: a time-boxed trial with real users and real data, with success criteria set before the pilot begins.
11. Document and hand over. Owner: tool owner. Output: for a built tool, documentation, access, and a named backup person; for a bought tool, an administration guide and the entry in the contract register.
12. Review at the date set. Owner: CFO. Output: usage, cost, and incident data compared with the original case, and a decision to continue, change, or retire.

Templates

Three-year cost comparison (copy into a spreadsheet)

Risk table

Decision memo

Metrics and KPIs

Setting targets without invented benchmarks. Do not apply a rule like "maintenance is a fixed percentage of build cost" from an article. Use your own record: for each internal tool the company has already built, divide actual annual maintenance hours by initial build hours and use the highest ratio as a cautious assumption for a new build. For build estimate variance, use the company's last projects. For adoption, set the goal as the share of intended users who do the job in the tool, measured in the pilot, rather than a general figure.

Common mistakes

1. Estimating the build, ignoring the maintenance. The first version is the cheapest part of owning software.
2. Comparing a bought tool's price to a built tool's hours. Put both on a loaded-cost, three-year basis, including administration of the bought tool.
3. Building a commodity. Writing your own expense tool or ticketing system is rarely a source of advantage.
4. Buying a platform and calling the gap a feature request. If a must-have is missing, price the workaround or the custom extension now.
5. No named owner. A tool without an owner decays. Choose the owner before you choose the option.
6. Key-person risk ignored. One person who understands the code or the configuration is a single point of failure. Require documentation and a backup.
7. Treating low-code as free of ownership. A low-code workflow that runs a critical process needs the same owner, documentation, and review as any other software.
8. Skipping the pilot. Real users with real data find the gaps that a demo hides.
9. Skipping contract review. Data export rights, price change terms, and code ownership in a commissioned build are matters for counsel.
10. No review date. A build decision that made sense for a company of 50 people may not for 200. Set a date to reconsider.

Worked example

Illustrative. All hours, rates, and prices are invented to show the method. They are not benchmarks.

A finance team needs a tool to route and approve vendor requests across 12 users. An engineer offers to build it. A vendor tool is available at a subscription. The loaded labor rate is $95 per hour.

Build:

Check: maintenance per year = 8 x 12 x $95 = $9,120; across three years = $27,360. Hosting = $1,800 x 3 = $5,400. $38,000 + $27,360 + $5,400 = $70,760.

Buy:

Check: subscription per year = 12 x $40 x 12 = $5,760; across three years = $17,280. Administration per year = 3 x 12 x $95 = $3,420; across three years = $10,260. $3,800 + $17,280 + $10,260 = $31,340.

Difference: $70,760 - $31,340 = $39,420 in favor of buying over three years.

What this tells the operator:

• Break-even for the build does not occur inside three years on these inputs. The build has an extra upfront cost of $38,000 against $3,800 for setup, a difference of $34,200, while its annual running cost ($10,920) is higher than buy's ($9,180), so it never catches up.
• The build only becomes the better choice if the bought tool leaves a must-have gap whose workaround cost exceeds the $39,420 difference, or if the process is a differentiator. Neither is stated here, so the test results point to buy.
• The build estimate has no contingency. If the company's earlier projects ran over estimates, the gap widens further.
• If the engineer leaves, the build has a single point of failure. The risk table should say so even though the cost table cannot.

AI prompt assistance

AI-assisted coding and low-code tools make building feel cheap. That is a reason to be more careful with the maintenance and ownership lines, not less. Use AI to structure and check the analysis, with your own data and your own verification.

1. Turn a request into a job statement.

Here is an email from a department asking for an internal tool. Write a one-paragraph job statement with the outcome, users, volume, and frequency. List every fact you had to assume and every question that must be answered before we can compare options.

Check: send the assumptions list back to the requester and have them confirm or correct each one.

2. Build the cost table.

I will paste hours, rates, subscription prices, and the number of seats for a build option and two buy options. Build a three-year cost table, show each calculation, and give the three-year totals and the difference between options.

Check: recompute each total in a spreadsheet, and confirm every input is from a written quote or an estimate with a named author.

3. Stress-test a build estimate.

Here is a build estimate with tasks and hours. Identify tasks that appear to be missing, such as authentication, access control, logging, backups, testing, documentation, and handover. List them without assigning hours.

Check: ask the builder to add hours for each missing task, and compare the revised estimate to prior projects.

4. Draft questions for a vendor.

Draft a list of questions to ask a software vendor about data export, uptime commitments, price changes at renewal, support response, and what happens to our data at termination. Do not give legal advice.

Check: counsel reviews the questions and the vendor's written answers.

Implementation guide

Governance: the business owner owns the outcome, the CFO owns the decision and the review, IT or security owns the risk assessment, and counsel owns commercial and licensing questions. Add every bought tool to the renewal calendar, and add every built tool to a simple register with an owner and a backup.

What to expect: the cost table often shifts the discussion from "can we build it" to "who will maintain it." That is the right shift.

Downloadable assets

The three-year cost comparison, risk table, and decision memo above are designed to be copied into a spreadsheet. There is no calculator for this topic.

Related resources

• Technology guides hub: all technology and systems guides.
• SaaS and vendor renewal calendar: track what you buy.
• Data foundations for operating reporting: what an internal tool reads and writes.
• ERP selection for PE portfolio companies: the larger version of this decision.
• AI use case prioritization framework: choosing which problems deserve effort.
• Technology due diligence for operators: how undocumented internal tools look to a buyer.
• The Tech Tax: recurring technology cost in context.

Frequently asked questions

When should a company build an internal tool instead of buying one?

Build when the process is a real source of difference, no established product does most of the job, you can name a long-term owner with allocated time, and data and uptime risks are manageable. For commodity functions such as expenses, ticketing, or standard approvals, buying is usually the better starting point. Test it with a three-year cost table.

What does a fair build vs buy cost comparison include?

A fair comparison covers initial build or setup, subscription, hosting, maintenance, administration, integrations, training, workaround cost for unmet requirements, and a contingency. Value internal hours at loaded cost on both sides, and use the same three-year period. Maintenance and administration are the lines that most often go missing.

How do you estimate maintenance cost for a custom tool?

Use your own record: for tools the company has already built, divide actual annual maintenance hours by initial build hours, and use the highest ratio as a cautious assumption. If there is no record, state the assumption openly and add contingency. Do not apply a general percentage from an article to your own situation.

Is low-code or AI-assisted building cheaper than traditional development?

It may lower the cost of the first version, but the tool still needs an owner, access control, documentation, backups, and review, so the ownership cost remains. Put those hours in the cost table. A low-code workflow that runs a critical process carries the same key-person and exit risks as custom software.

How often should a build or buy decision be reviewed?

Review at a date set in the decision memo, commonly at the first renewal or after a year of use, and sooner if volume, headcount, or systems change. Compare actual usage, cost, and incidents with the original case, then decide to continue, change, or retire the tool.

How this works in a System of Performance

A build or buy decision rests on assumptions about usage, hours, and cost that are rarely revisited. A Performis routine can take on a recurring job like this, with the scope and fit agreed with you: it works from the records your team supplies, prepares the work for your named reviewer, and keeps each approval on record. If you want to see where your own tools and costs stand, bring it to us as a launch partner.