The default SaaS cost projection in a build vs buy spreadsheet looks something like this: take the year-one quoted price, multiply by five, and call that the buy column. The math is wrong in a specific direction. The year-one price is the discounted price; subsequent years escalate. The renewal at the end of the initial term is where the vendor exercises their pricing power. A 5-year projection that ignores both of these is undercounting the buy column by 30 to 80 percent.
This piece is a practical walkthrough of how to build a more honest 5-year SaaS cost projection. The math is not hard. The discipline of using realistic numbers is the part that gets skipped.
Photo by Kaique Rocha on Pexels
Step 1: Identify the contract structure
SaaS contracts come in a few common shapes. The shape matters because each one has a different escalator pattern.
1-year contract, monthly billing. The vendor can re-price at every annual renewal with full pricing freedom. Year-over-year increases of 10 to 25 percent are typical for category-leading vendors with healthy growth.
3-year contract, annual prepay with discount. The vendor often locks year-1, 2, and 3 pricing inside the contract. Years 4 and beyond are renewal pricing, where the vendor's leverage is high because switching cost has accumulated. Year-4 prices often step up 30 to 80 percent versus year-3.
Multi-year enterprise contract with named accounts and capped escalators. Larger deals sometimes include explicit caps on year-over-year increases (CPI plus a percentage, or a fixed cap like 5 percent annually). When these caps exist, the model is straightforward. When they do not, the model needs to estimate likely vendor behavior.
Step 2: Map the contract to a 5-year cost curve
For each year of the projection, write down the assumed price. Use the actual contracted price for years that are locked in. For renewal years, use a stress range rather than a single number.
A worked example: a 3-year contract at $80,000 per year, with year-1 implementation included. Years 4 and 5 are renewal pricing.
| Year | Locked? | Assumed price |
|---|---|---|
| 1 | Yes | $80,000 |
| 2 | Yes | $80,000 |
| 3 | Yes | $80,000 |
| 4 | No | $112,000 (40 percent step up at renewal) |
| 5 | No | $123,200 (10 percent year-over-year on the new base) |
Five-year total: $475,200, against a naive five-year projection of $400,000. The naive projection undercounts by 19 percent. That undercounting is the size of the typical year-4 step-up alone; adding a contribution interruption or other unmodeled events makes the gap larger.
Step 3: Add the often-skipped cost lines
Three cost lines are typically missing from the buy column of the spreadsheet:
Implementation cost beyond the bundled allowance. Most vendor implementation packages include a fixed number of hours of professional services. Real-world implementations often exceed that allowance, especially when the integration is non-standard. Budget 25 to 50 percent over the quoted implementation fee unless the vendor has signed a fixed-price contract for the full work.
Integration code on your side. Even with vendor-provided implementation, your team writes the code that connects the vendor's system to yours. SSO configuration, data feeds, webhook handlers, custom field mappings, audit log integrations. Estimate the engineering hours required and convert to dollars at your loaded engineering rate. This is the part of the buy column that most resembles the build column, and it deserves the same accounting treatment.
Ongoing integration maintenance. The integration code does not stay static. Vendor API changes, internal system changes, and feature additions all require ongoing maintenance. Budget 15 to 25 percent of the original integration cost per year as ongoing maintenance.
The Wikipedia article on total cost of ownership carries the formal cost categories, and the Project Management Institute library has practitioner-level frameworks for vendor lifecycle cost modeling.
Step 4: Model the vendor pricing escalator with a stress range
The year-4 renewal price is the single largest unknown in the projection. Rather than picking one number, model three:
- Base case: 30 percent step up at renewal, 10 percent year-over-year afterwards.
- Stress case: 60 percent step up at renewal, 15 percent year-over-year afterwards.
- Worst case: 100 percent step up at renewal, 20 percent year-over-year afterwards.
The base case is what most vendors will quote you in private; the stress case is what often actually happens; the worst case is what category-leading vendors with strong lock-in have been known to push for at renewal.
Run the full 5-year projection at all three escalator scenarios. The spread between them is the model's exposure to vendor pricing power. If the spread is large, the decision is fragile to vendor behavior in a way that should be modeled explicitly in the build vs buy analysis.
Step 5: Compute the equivalent build column
The build column has its own cost shape. Year 1 has the highest cost (initial development plus opportunity cost from the engineering effort). Years 2 through 5 carry maintenance, incremental feature work, and occasional larger investments. The total over 5 years often crosses the buy total at some point in years 3 through 4 of a typical SaaS deal.
A defensible build column has these lines:
- Initial development cost (engineering hours times loaded rate, plus a 20 percent buffer for overruns).
- Year-2 through year-5 maintenance (typically 15 to 25 percent of initial development annually).
- Incremental feature work (varies by what the tool needs to grow into).
- On-call and operational burden (engineering hours per month for production support).
- The cost of the engineering capacity diverted from other work (opportunity cost).
The opportunity cost line is often missing from build vs buy spreadsheets and is the single largest argument against build in many situations. It deserves an explicit number, not a vague gesture.
Step 6: Report both columns at all three escalator scenarios
The output of the analysis is six numbers: build total at the three escalator scenarios (which are constant for build), and buy total at the three escalator scenarios (which vary significantly).
If buy is cheaper at all three scenarios, the answer is buy unless other factors (strategic fit, switching cost, operational ownership) tip the analysis the other way.
If build is cheaper at the stress and worst case but buy is cheaper at the base case, the decision depends on how confident you are in the vendor's behavior at year-4 renewal. A conservative analysis treats the stress case as the realistic case, not the base case.
If build is cheaper at all three scenarios, the answer is build, full stop.
The hub article on how to run a build vs buy analysis walks through how the cost projection interacts with the other dimensions of the decision (operational ownership, strategic fit, switching cost). At 137Foundry, we walk through this kind of cost modeling with clients as part of broader services engagements, often alongside the data integration or AI automation work the project is actually about. The main site carries the case studies. The Federal Trade Commission materials on vendor relationships are a useful complement when the procurement side of the analysis needs more rigor.
A short checklist
- Use actual contracted prices for locked-in years, not the year-1 quote multiplied out.
- Model year-4 and year-5 at a stress range, not a single number.
- Add implementation overrun, integration code, and ongoing maintenance lines.
- Compute the build column with engineering opportunity cost included.
- Compare both columns at all three escalator scenarios before recommending.
A 5-year SaaS cost projection done this way takes about 90 minutes more than the naive version. It also produces a number that survives contact with the actual renewal cycle, which the naive version does not.
Top comments (0)