When to Build a Web App Instead of Buying SaaS
The default answer in 2026 is “buy SaaS.” It’s the right answer most of the time. The problem is the most of the time part — when SaaS is wrong, it’s expensively wrong. The build-vs-buy decision deserves more rigor than the conventional wisdom suggests.
Three questions decide it. None of them are about cost.
Question one: how unique is your workflow?
If five other companies in your industry run essentially the same workflow you do, SaaS is right. The vendors building for that workflow have accumulated more domain knowledge than you can afford to develop, and you’d spend more rebuilding it than you’d save by skipping the license fee.
If your workflow is genuinely unusual — driven by a business model, regulatory environment, or competitive position no off-the-shelf vendor has built for — SaaS is wrong. You’ll spend the next three years bending the SaaS to fit your shape, paying for features you don’t use, and writing custom code on top of it anyway.
The signal: when you evaluate three SaaS vendors and the demos all show 30% of what you actually need, the gap isn’t something the next vendor solves. The gap is the workflow itself.
A logistics client we worked with had been bending Salesforce Service Cloud for four years to fit their dispatch workflow. The Apex they’d written to make it work was longer than the custom app we eventually built to replace it.
Question two: where does the data live, and who can see it?
SaaS vendors have improved dramatically on data residency and privacy. They have not solved it. Some of your data has constraints that make SaaS architecturally awkward:
- Data that can’t leave a specific region (regulatory)
- Data that can’t be processed by sub-processors (contractual)
- Data that needs to be cross-referenced with on-prem records in real time (architectural)
If your workflow involves data with any of those constraints, SaaS adds a complexity tax that often exceeds the cost of the custom build. Custom apps that deploy alongside your existing infrastructure don’t have a residency story to tell — the data never moves.
Question three: what’s your exit cost?
This is the question that closes the case more often than the other two. Imagine you’re three years into the SaaS relationship and the vendor:
- Triples their pricing (it happens)
- Gets acquired by a competitor of yours (it happens)
- Discontinues the product or pivots away from your segment (it happens)
- Has a security incident that requires you to migrate (it happens)
For each, what does it cost you to switch?
If the answer is “we’d lose six months of operations and an unknowable amount of historical context,” the vendor lock-in is the real cost of the SaaS, not the monthly fee. Custom apps have no exit cost because there’s no exit — the code is yours.
The frame that helps:
Decision rule: if (5-year exit risk × estimated migration cost) > (custom build cost + 5 years of maintenance), build.
For most internal workflows in the mid-market, that math comes out to “build” more often than people expect.
What custom actually costs
The other reason SaaS feels easier is that the cost of “build” is usually overstated. A focused custom app for an internal workflow is typically:
- 4–8 weeks of engineering for the first useful version
- 10–20% of that, annually, in maintenance
- Cost of hosting (cloud or on-prem; usually a rounding error)
A SaaS license at $100/seat/month for 200 users is $240k/year. A 6-week custom build is $40–80k once and ~$8–16k/year after. The crossover happens in year one if usage is above 100 seats.
What we’d do
The hardest part of the build-vs-buy decision is being honest about which question is actually load-bearing for your situation. We run that conversation in 60 minutes and tell you which way the answer falls — sometimes the answer is “buy SaaS,” and we’ll say so.
Our Forge product is the four-week sprint when “build” wins. See Forge → · Book a discovery call →