Every few months a client asks me some version of the same question: should we keep paying for this SaaS tool, or should we just build our own? For a decade the honest default answer was "buy it — you underestimate the build". In 2026 that default no longer holds, but not for the reason most people think. AI changed the math on both sides of the equation at once.
The math changed twice
The obvious change is that custom software got cheaper to build. In my own Laravel work, a CRUD-heavy internal tool that would have taken me six weeks in 2022 — models, migrations, admin panel, permissions, exports — now takes two to three. AI-assisted development compresses exactly the repetitive middle of a build: scaffolding, test coverage, integration glue. Surveys back up what freelancers see daily: roughly a third of teams report having already replaced at least one SaaS subscription with custom software.
The less obvious change is that SaaS vendors got the same productivity boost. The tool you are thinking of replacing ships features faster than it did three years ago, and its AI features improve every quarter. So while the cost of building fell, the bar your custom build has to clear rose. Anyone who only accounts for the first effect ends up with a half-finished internal clone of a product that meanwhile got better.
The framework: differentiation and data, or commodity and compliance
Martin Fowler's old distinction between utility and strategic software is more relevant than ever — AI just moved the boundary. My version of it for 2026:
Build when the software is your edge
- Differentiation. If the workflow is how you win deals or serve customers differently from competitors, a generic tool actively flattens your advantage. This is where custom pays for itself.
- Data ownership. If the data in the tool feeds your pricing, your AI features, or your reporting, owning the schema and the raw records is worth real money. Exporting CSVs from a vendor is not ownership.
- Integration depth. When a tool needs to talk to three internal systems and the vendor's API covers half of what you need, the integration workarounds often cost more than a purpose-built module.
Buy when the software is plumbing
- Commodity workflows. Payroll, accounting, email delivery, video calls. You gain nothing from a bespoke version and inherit all the edge cases.
- Compliance-heavy domains. Anything where the vendor carries certification burden — payment processing, e-signatures, bookkeeping under Finnish or EU rules. Their compliance team is part of the price.
- Products with network effects. You cannot build your own LinkedIn or your own app store presence.
The worked example: per-seat SaaS vs three-year custom TCO
Numbers make the decision concrete. The comparison I run with clients is per-seat SaaS spend against a three-year total cost of ownership for a custom build:
3-year TCO (custom) = build cost
+ 3 × (0.15–0.25 × build cost) // maintenance
+ 3 × hosting/ops
3-year TCO (SaaS) = seats × price × 36 months × (1 + expected price increases)| Scenario | SaaS, 3 years | Custom, 3 years | Verdict |
|---|---|---|---|
| 25 seats, €18/seat/mo project tool | ≈ €17,000 | €20,000 build + €11,000 maintenance ≈ €31,000 | Buy |
| 60 seats, €40/seat/mo ops platform, half the features used | ≈ €92,000 | €35,000 focused build + €18,000 maintenance ≈ €53,000 | Build |
| 3 overlapping tools consolidated into one internal app | ≈ €60,000 combined | €30,000 build + €15,000 maintenance ≈ €45,000 | Build, usually |
Two things decide most cases. First, seat count: per-seat pricing scales linearly with headcount while a custom build does not, so somewhere between 30 and 60 seats the lines cross for mid-priced tools. Second, feature utilisation: if a team uses 30% of a platform, a custom build only has to replicate that 30% — which is exactly the kind of scoped, well-specified project that AI-assisted development makes cheap.
The trap on each side
The build-side trap is maintenance denial. Software is not done when it ships; budget 15–25% of the build cost per year or the tool rots. AI assistance lowers this too — upgrades and small fixes are faster than they were — but it does not make it zero, and someone has to own the tool. If no one inside the company will own it, buy.
A related build-side trap is scope creep disguised as ambition: the moment a focused internal tool tries to become "our platform", the three-year numbers above stop applying. The builds that pay off are the boring ones — a fixed scope, one owner, and a deliberate decision to not replicate the vendor's other seventy features. Hold that line and the maintenance estimate stays honest; lose it and you have simply founded an unfunded software company inside your own.
The buy-side trap is subscription sprawl plus data lock-in. I have audited companies paying for eleven tools with overlapping features, none of which talk to each other, with the company's operational history scattered across all of them. The per-tool cost looked fine; the aggregate was a five-figure annual bill for a fragmented dataset they could not use for the AI and analytics features they actually wanted to build.
Build for differentiation and data ownership. Buy for commodity and compliance. AI lowered the cost of building — but it also raised the bar your build has to clear, so run the three-year numbers before you commit either way.
How I run this decision with clients
In practice it is a two-hour exercise: list the workflows, mark each as differentiating or commodity, pull the real per-seat spend from the invoices, and estimate a scoped build for the differentiating ones. Most companies end up with a hybrid — keep buying the plumbing, build the two or three workflows where owning the software and the data actually compounds. That is usually where my project work starts.
Weighing a subscription bill against a custom build for your team? I do exactly this analysis — and the build, if the numbers say so. Let's talk it through.