Buy software when it is plumbing — a solved problem where you gain nothing from being different (auth, email, payments, accounting). Build software when it is the differentiator — the thing customers actually choose you for. The economics decide the middle ground: over three to five years, buying costs 2–4x its sticker price in configuration, integration and per-seat fees, while building costs 2–3x its quote in maintenance. The framework below settles which side your decision falls on.
The real cost of buying
The sticker price is the entry fee, not the total. The full math over three years:
- Licences: per-seat × headcount × 36 months — the line that quietly triples as the company grows
- Configuration: getting the product to fit your workflows — 20–100% of first-year fees in consultant time
- Integration: connecting it to everything else you run — often the largest hidden line
- Switching costs: data extraction, retraining, process rework — measurable in months, felt at renewal time
The strategic cost is vendor risk: pricing changes, feature deprecations, roadmap pivots you do not control, and acquisition outcomes that orphan the product. None appear in any invoice; all appear in the exit.
The real cost of building
The quote is similarly optimistic. Building costs:
- The build: the number you were quoted
- Maintenance: 15–20% of build cost, every year — the forever line most buyers forget
- Opportunity cost: engineering attention spent on plumbing instead of product
- Capability risk: needing the team forever, or documentation good enough not to
What buying never gives you and building always does: exact fit, no per-seat scaling, and ownership of the asset — the custom software cost guide covers when that ownership is worth it.
The decision framework
Five questions, in order:
- Does this software differentiate us? If customers choose you because of it → build. If it just needs to exist → buy.
- Is the requirement standard or unusual? Standard (payroll, email, auth) → buy. A workflow nobody has → the market has nothing to sell you anyway.
- What does the 5-year math say? Licences plus configuration plus integration versus build plus maintenance. Crossover usually sits around 40–80 seats or unique workflows.
- Do we have, or can we get, the capability to own it? Honest answer required — building without capability is renting with extra steps.
- How fast do we need it? Buying deploys this quarter; building owns the timeline. Urgency favours buying, even at worse economics.
The pattern that works: buy the plumbing, build the house
Mature architectures buy the solved layers — authentication, payments, email delivery, monitoring — and build the two or three layers that ARE the business: the core workflow, the data model, the customer experience. This is why modern SaaS products are 70% rented infrastructure and 30% owned magic. The MVP cost guide applies the same discipline to first versions.
Where the answer flips
- From buy to build: licence costs scaling with success, vendor roadmaps diverging from your strategy, configuration exceeding the cost of code, compliance requiring control the vendor will not give
- From build to buy: maintenance burden exceeding value, the problem becoming standardised in the market, team attention needed elsewhere
Both flips happen to healthy companies — revisiting the decision every 18–24 months is a sign of management, not indecision.
How we see it play out
Most engagements we take start with the framework applied honestly: sometimes the answer is our ready products — the bought option; sometimes it is custom development; and sometimes it is buying now with a build path documented for when the economics flip. See how we price both paths, or bring the specific decision to a scoping call — the framework above is genuinely the one we apply.
Frequently asked questions.
Should I build or buy software?
Buy plumbing — solved problems where differentiation adds nothing (auth, payments, email). Build differentiators — the workflows customers choose you for. The middle ground is 5-year economics: licences plus configuration plus integration versus build plus 15–20% annual maintenance.
What are the hidden costs of buying software?
Configuration (20–100% of first-year fees), integration with existing systems, per-seat licence scaling as headcount grows, and switching costs that effectively lock you in at renewal. The strategic cost is vendor risk: pricing, deprecations and roadmap changes outside your control.
What are the hidden costs of building software?
Maintenance at 15–20% of build cost every year, the opportunity cost of engineering attention, and the capability commitment — you need the team or documentation good enough to survive them. The quote is the entry price, not the total.
When does building become cheaper than buying?
The crossover typically sits at 40–80 seats or when workflows are unusual enough that configuration exceeds code. Licence costs scaling with success is the most common trigger — the moment your growth becomes your vendor's revenue.
Can I buy now and build later?
Yes — and documenting the build path while buying is a discipline we recommend. Buy to validate fast, build when economics or strategy justify it, and revisit every 18–24 months. The flips in both directions happen to healthy companies.
Enjoyed this? Let's talk about applying it to your product.
