Build vs Buy: 4 Questions to Ask Before Deciding

"Should we build or buy?" is the wrong question. It's binary, when the real decision is rarely binary. Most companies need a mix — SaaS for commodity functions, custom for the workflows that actually matter. Better: ask these four questions, and the answer becomes obvious.

Question 1: Is this workflow a competitive advantage, or a commodity?

Email. Accounting. Payroll. Video calls. These are commodities — your customers don't care how you do them, only that you do them. Buy SaaS. Don't reinvent.

Your actual product, your fulfilment process, your customer-onboarding ritual, your service-quality system — these might be the things that make customers choose you over competitors. If you do them the same as everyone else (using the same SaaS as everyone else), you've levelled the playing field with your competitors.

A good test: if a board deck described your operations, would the line "we use [Big SaaS] like everyone else in our industry" be a strength or a weakness? Usually it's a weakness. That's where custom wins.

Question 2: What's the 5-year cost — not the year-1 cost?

SaaS sells year-1 cost because that's when the math looks best. A $50/seat tool with 20 seats is $12k/year. Compared to a $50k custom build, SaaS wins year 1 by $38k.

Now run it five years. Add 8% annual price increases (industry standard). Add modest growth — 5 new seats per year. You land somewhere around $115k of cumulative SaaS spend. Custom build at roughly $8k/year light maintenance = $90k cumulative. Custom wins by $25k+ over five years.

That's at modest growth. At realistic mid-market growth (25 to 50 seats over 5 years), SaaS costs balloon past $200k. The gap to custom grows every year after breakeven, while SaaS pricing keeps climbing.

Question 3: What's the workaround tax we're paying right now?

Open your team's Notion or shared docs. Count the playbooks that exist because the SaaS doesn't quite work for your process. Count the spreadsheets people copy data into. Count the Zaps someone built. Count the manual reconciliation jobs.

These workarounds have real costs:

Hours each week — multiply by salary, multiply by 52, multiply by team size

Onboarding tax for new hires — they have to learn the workarounds too

Error rate from manual data movement

Lost work when the workarounds break (and they always break)

I've seen 25-person ops teams spending 800+ hours/year on SaaS workarounds. At $50/hour fully loaded, that's $40k/year of pure friction. Custom software fundamentally removes this tax — not partially, not mostly, fundamentally — because the software is designed around how you actually work.

Question 4: What's the exit story if this vendor disappears?

This is the question nobody asks until it's too late. If your SaaS vendor gets acquired, pivots strategy, raises prices 3x, or simply shuts down — what's your plan?

For most companies the honest answer is: "we'd be in serious trouble for 3 to 6 months." Their data lives in a vendor system with limited export. Their workflows assume vendor-specific features. Their team is trained on vendor-specific UX.

Custom software means: you own the code, you own the data, you can self-host or migrate cloud, you can extend it as needs change. There's no exit story to worry about because there's no vendor to exit from. That's not paranoia — that's optionality, and optionality compounds over time.

How to use these answers

If you answered:

Competitive advantage + brutal 5-year SaaS cost + high workaround tax + real exit risk → Build custom. This is exactly the situation custom was designed for.

Commodity workflow + cheaper SaaS + minimal workarounds + low lock-in worry → Stick with SaaS. Don't fix what isn't broken.

Mixed answers → Hybrid is almost always right. Keep SaaS for commodity functions; build custom for the 1–2 workflows that actually differentiate your business.

If you want a transparent cost estimate for the custom path, our cost calculator takes 60 seconds. Or browse 240+ products across 34 industries we've already built — yours probably maps to one of them.