"Just buy SaaS" was the right answer in 2018. A meaningful internal application meant a six-figure quote, a nine-month timeline, and roughly a coin-flip on whether the result would be usable. Against that, a $50/seat/month subscription with a 30-day onboarding looked like the responsible choice — because it was.
In 2026, the math is different. Quietly, and most companies haven't redone it.
This post is the redo.
The Old Math
Custom software earned its scary reputation honestly.
- Cost. A meaningful internal app ran $200–500K, plus the consulting markup most buyers paid on top of that.
- Timeline. Six to nine months from kickoff to working software was the good outcome. Twelve to eighteen wasn't unusual.
- Failure rate. Industry studies put project failure — delivered late, over budget, or never used — somewhere between 40% and 70%, depending on whose study you trust. Pick any number in that range and it's bad.
- Maintenance. A codebase nobody on staff fully understood became a liability the moment the original team rotated off. The cost didn't stop at delivery.
Against those numbers, a SaaS subscription was the rational pick for almost everything. This isn't a story about anyone making mistakes. It's a story about a constraint that has since changed.
What Changed
What changed is AI-augmented development.
I've written about this from the developer side in Why I Build Software with Claude Code and Two Months of Claude. For a buyer-facing summary, the relevant facts are simpler than the hype suggests:
- Senior engineers using tools like Claude Code now ship in weeks what used to take months.
- The codebases produced are smaller, because the AI generates only what's needed for the actual requirements — not the framework bloat that comes inherited from a SaaS vendor serving 10,000 other customers.
- Tests and documentation come along for the ride instead of being deferred to a phase that never arrives.
- The economic floor of "we have software" used to require enough scale to justify $500K in engineering. That floor has dropped sharply.
This site is a small proof point. The Services page mentions it was built in a single development session — design, content, deployment, the whole thing. That sentence is meant literally, not aspirationally. It's not the kind of project that would have been a single session in 2022, and it's not unique now.
The New Math
Plug the new constraints into the same decision a 2018 buyer was making, and the answer moves.
| Old Math (2018) | New Math (2026) | |
|---|---|---|
| Cost | $200–500K | $30–60K typical |
| Timeline | 6–9 months | 2–8 weeks |
| Maintenance | Large codebase, dedicated team | Smaller surface area, lighter ongoing burden |
| Risk | High — long horizon, big bet | Low — small horizon, recoverable |
The maintenance row is the one that surprises most buyers. The intuition is that custom software is always heavier to maintain than SaaS — that's the implicit pitch behind every renewal email. It used to be true. It's increasingly not. A focused codebase built for your specific workflow has less surface area than a SaaS tool built to serve every adjacent use case across an entire industry. You maintain what you actually use.
The risk row matters too. A two-week build that fails is recoverable in a week. A nine-month build that fails is the reason the orthodoxy existed.
Decisions That Flip
The point isn't that custom always wins. The point is that several decisions landed on SaaS by default that wouldn't survive a redo today.
The customized CRM. You bought it because every SaaS sales pitch promised "configurable to your workflow." Three years and a hundred-twenty thousand dollars of subscription later, it's been configured into something nobody on your team can change without breaking the next thing. A custom build now would cost less than next year's renewals and produce software you actually own.
The per-seat SaaS you've outgrown. Thirty seats at $50 a month is $18,000 a year. Over five years, $90,000. The custom equivalent is one build, paid once. If you keep growing, that gap widens. If you shrink, the SaaS bill doesn't shrink with you.
The "industry standard" tool nobody uses. Every team has at least one. The ROI of replacing it isn't features — it's user adoption. Software your team actually uses produces value. Software they don't isn't free just because the seats are paid for.
The reporting tool that exports to Excel. If the workflow ends in "export and reformat in Excel," the SaaS isn't reporting. It's a database with a paywall.
What Still Favors SaaS
The post would be dishonest without this section. Custom isn't always the answer.
- Payroll, banking, regulated finance. You aren't buying software; you're buying compliance work, audit trails, and indemnification. That stack is worth paying for.
- Cloud infrastructure, email, calendars, identity. Commodity at a scale you'll never match. Reinventing them is a waste of the new math.
- Anywhere the network effect is the product. Slack isn't worth replicating because the value is who's in the room, not the rooms themselves. Same for most communication tools.
- When you'd be the first user of your own software. If your business case for custom assumes processes you haven't yet run on SaaS, build the processes first. SaaS is a fast way to learn what you actually need before you commit to building it.
The working framework: SaaS for commodity, custom for the parts where your workflow is the product. The 2018 default got the commodity half right and the workflow half wrong, because the workflow half was too expensive to build. It isn't anymore.
The Hidden Asset
The piece most ROI conversations miss: software you own appreciates as your business evolves. The codebase grows with you. Software you rent depreciates the moment your needs change — the vendor's roadmap is for their median customer, not for you.
Over a five-year horizon, that's not a small difference. The five-year TCO comparison rarely accounts for the strategic optionality of owning the asset. You can change it. You can integrate it. You can hand it to a different team. The renewal bill doesn't get to vote on your product direction.
The Honest Caveat
The new math assumes experienced engineering judgment in the loop. AI-augmented development done badly produces the brain-fry and broken-code scenario I wrote about in The Real Cost of Moving Fast with AI — Amazon's 6.3 million lost orders, the BCG study on cognitive overload, the 1.7x increase in defects in unreviewed AI-generated code. Those are real costs of getting this wrong.
The failure mode is junior teams shipping AI output without review. The success mode is senior engineers using AI to compress what they already knew how to build. The cost numbers in this post assume the second mode. If you can't tell which mode a prospective build is in, that's a vendor question before it's a build-vs-buy question.
The Question Worth Asking
The orthodoxy I started this post with — just buy SaaS — was earned, not arbitrary. It was the right default for the constraints of its decade. Those constraints have moved. The default hasn't, in most companies' decision trees, which means a lot of subscription dollars are flowing on a calculation that no longer holds.
Here's the question worth sitting with: of your top SaaS line items right now, which would you have built if you'd known it would take three weeks?
That's the line items to redo the math on first.
For a closer look at the cost of leaving the math undone, The Hidden Cost of Standing Still covers what delay is actually costing the businesses that haven't reopened the question. And if your starting point is closer to "we still run this on spreadsheets," 5 Signs Your Business Has Outgrown Spreadsheets is the earlier checkpoint on the same decision path.