Build or Buy AI SaaS? Calculate the Break-Even Point

What is the short answer?

For a company under 200 people, buy SaaS when the custom tool's monthly saving cannot repay its build cost inside the period you expect the model, connector or workflow to remain useful. Put every cost in a 24-month spreadsheet, price internal time at its loaded employer cost, add security and maintenance, then divide the extra upfront build cost by the monthly saving. If the result is 32 months, you are financing a rewrite.

That is the answer I would give an owner before opening a code editor. Cheap API calls make custom builds look clever. The invoice arrives later, usually as maintenance work nobody put in the quote.

How do I define the two options before comparing them?

Write down one job, one user group and one decision date. “An AI assistant” is too vague to cost. “Classify incoming service emails and suggest a reply for 12 coordinators” is costable. So is “search our policy documents for the operations team.”

For the buy option, record the actual plan, number of seats, contract term, implementation hours and any required base subscription. Use vendor pricing pages, not a screenshot from a sales call. Microsoft’s Copilot pricing page, OpenAI’s API pricing documentation, and Anthropic’s pricing page are useful starting points, but prices and limits change. Put the date beside each number.

For the build option, describe the smallest working system. Include the interface, data sources, authentication, model provider, logging, review path and owner. If the proposed build has no named owner for month six, it is a demo with a future tense.

What costs belong in the build total?

Start with labour. Count discovery, design, development, data cleanup, testing, deployment and internal training. Price employee time at loaded cost, not salary divided by 2,080. Benefits, payroll taxes and the value of work pushed aside belong in the estimate. The U.S. Bureau of Labor Statistics software developer profile lists a May 2025 median wage of $135,980 for software developers. That is a wage reference, not your company’s loaded rate.

Then add the costs that make a private tool a business system: identity and permissions, audit logs, backups, monitoring, incident response, vendor review, data retention and testing after model changes. A hosted product may include some of these. Your spreadsheet should still show them, even when the number is zero because a control is genuinely unnecessary.

Finally, add opportunity cost. If your best engineer spends 180 hours on an internal assistant, what work moves? I have seen “free internal capacity” turn into a delayed billing automation project. That delay is part of the build decision, even if it never appears on an invoice.

How do I calculate the SaaS cost without fooling myself?

SaaS cost is more than seats multiplied by a list price. Add setup time, data connection work, admin time, training, usage overages, premium seats and the base licence the vendor requires. Reserve a small, explicit amount for migration. The reserve is not a prediction of failure. It is a way to stop lock-in being treated as somebody else’s problem.

If a vendor bills annually, show the cash commitment separately from the monthly equivalent. A $20 seat paid for 12 months is $240 of commitment, even if the spreadsheet displays $20 per month. That distinction matters when a 50-person company wants to test a tool with eight users first.

Use the same service level in both columns. Comparing a SaaS assistant with support and access controls against a home-built script that has neither is a neat way to manufacture a win.

What is the break-even formula?

Choose a horizon, usually 24 months for a fast-moving AI workflow. Calculate:

Build TCO at month t = build costs upfront + (build monthly costs x t)
Buy TCO at month t = buy costs upfront + (buy monthly costs x t)
Upfront build premium = build upfront costs - buy upfront costs
Monthly build saving = buy monthly costs - build monthly costs
Break-even months = upfront build premium / monthly build saving

If monthly build saving is zero or negative, the build never breaks even on cost. If the answer is longer than your useful-life assumption, stop calling it a cost-saving project. It may still be a product or a data-control decision, but that is a different argument.

This is a cash model, not a promise about revenue. If the tool creates measurable new revenue, model that separately and show the assumptions. Do not hide optimistic revenue inside “savings.”

Can you show me a worked example with real arithmetic?

Here is a hypothetical example, with illustrative numbers rather than a client case. An 85-person logistics company wants document search and triage for 50 operations staff. The buy option costs $1,400 per month in seats, $300 per month for internal administration, $3,000 for setup and $1,500 held for future migration. Its upfront total is $4,500 and its monthly total is $1,700.

The build estimate is $17,100 for 180 developer hours at a hypothetical loaded rate of $95, $2,850 for security work, and $5,000 for delayed work elsewhere. That makes $24,950 upfront. Monthly costs are $210 for hosting and model usage, $760 for eight maintenance hours, and $95 for access reviews and patching. The build total is $1,065 per month.

The build premium is $20,450. Monthly saving is $635.

$20,450 / $635 = 32.2 months

At 24 months, buy costs $45,300. Build costs $50,510. The custom system is cheaper only after month 32, assuming every estimate survives contact with production. I would buy in this case. The horizon is too long for a small company to pretend the model and connectors will sit still.

A different workflow can reverse the result. Suppose a headless background process serves 150 employees without 150 paid seats, and its monthly SaaS alternative is $3,000 higher. The same build premium could repay in under a year. That is a hypothetical sensitivity test, not a claim about any vendor’s price.

Which assumptions deserve a sensitivity test?

Change one input at a time and watch the result. I test these first:

• Maintenance hours per month. Double them. Eight hours sounds tidy until a connector breaks on a Friday.
• Active users. Price the case at 25, 50 and 100 users, using the vendor’s current plan rules.
• Build delay. Add four weeks to the schedule and price the work that slips.
• Model and usage cost. Use a low, expected and high volume based on a short pilot, not a confident guess.
• Useful life. Run 12, 18 and 24 months.

If the decision changes every time you touch an assumption, do a small paid pilot before building. The spreadsheet is telling you that the decision is uncertain. Listen to it.

When should a small company build anyway?

Build when the workflow is narrow, repeated often and tied to data or actions that generic SaaS cannot handle cleanly. A background classification job can be a better build candidate than a company-wide chat interface because it may avoid per-seat pricing and keep the user experience inside an existing system.

Build also when control is the actual requirement. The NIST AI Risk Management Framework says organisations should examine expected benefits and costs, including non-monetary costs from errors and trustworthiness. That supports putting data exposure, review time and failure handling in the model. It does not prove that self-hosting is cheaper.

Do not build because your team can make a prototype over a weekend. I can make a prototype over a weekend too. The question is who owns it after the first provider change, access review or angry user.

What should I do this week?

Pick one workflow and create two columns in a spreadsheet. Ask the buy vendor for the exact plan and usage terms in writing. Ask the internal builder for hours by phase, a monthly maintenance allowance and the controls the tool will need. Add a row called “work displaced.”

Run the formula at 12, 18 and 24 months. If buy wins at all three horizons, buy it and spend your engineering time on the integration that makes it useful. If build wins only at 24 months, run a pilot and revisit the estimates. If build wins quickly because the SaaS alternative charges per seat, now you have a credible case to fund a narrow system.

If you want a second pair of eyes on the model, contact DeuceWorks with the workflow, seat count and your two monthly estimates. I would rather find a bad assumption in a spreadsheet than a year into a custom tool.