There’s a default in startup land: when you need a new piece of internal software, you buy a SaaS subscription. CRM? Salesforce or HubSpot. Project management? Asana or Linear. Customer support? Intercom or Zendesk. Billing? Stripe Billing or Chargebee. The reasoning has always been: building takes months, hiring engineers is expensive, and somebody else has already solved this — why reinvent the wheel?
That math is shifting. Not for everything, but for more cases than most teams realize. We’re going to walk through when buying is still right, when it’s suddenly the more expensive option, and three questions you can ask to figure out which side of the line you’re on.
The math everyone runs
Take a 20-person team using a SaaS product at $50 per user per month. That’s $1,000/month, $12,000/year, and the price typically goes up 10–20% a year. Five years in, you’re paying $15,000–$20,000/year for a tool you may have outgrown two upgrades ago.
Compare to custom software. Eighteen months ago, building a focused internal tool that replaced one of those SaaS products would have cost $80,000–$150,000 in engineering time, plus ongoing maintenance. So the SaaS subscription was clearly cheaper, even on a five-year horizon.
That hasn’t been true for about a year. With AI-assisted development, the build cost on focused, well-scoped internal tools has dropped to roughly $15,000–$30,000 — a 5–10x reduction, depending on the tool. That’s suddenly competitive with two years of subscription, before you’ve even factored in the things SaaS pricing hides.
What SaaS pricing hides
Three costs founders consistently underestimate:
1. Vendor lock-in. Your data is in their schema. Migrating to a different tool — or building your own later — means engineering time to extract, transform, and re-import everything, often with gaps where the old vendor’s feature set didn’t map cleanly.
2. The 30% of features you don’t use, plus the 30% you wish existed. Most SaaS products are built for a median customer. If your workflow doesn’t look like the median, you’re paying for features you don’t need and working around the absence of features that would actually save you time.
3. Per-seat pricing as you grow. $50/user/month is fine at 20 users. At 80 users, it’s $48,000/year. The SaaS company’s incentive is for you to have more seats, not fewer. The custom alternative scales for free with team size.
When buying still makes sense
Three situations where the SaaS default is still the right call:
The workflow is genuinely commodity. If what you need is a calendar, an email inbox, a basic chat tool, a generic file storage system — the SaaS players have spent thousands of engineer-years on these. You will not build a better one. Buy.
The vendor handles things you don’t want to. Email deliverability, payment compliance, SOC 2-grade audit trails — these are gnarly enough that paying someone to handle them is almost always worth it. (We use Resend for email and Stripe for payments for exactly this reason.)
You need it next week. A four-week build is still longer than a one-day signup. If timing dominates, buy now and reconsider in six months.
When building wins
Two situations where building beats buying, and they’re becoming more common:
The workflow is deeply specific to your business. You don’t want a generic CRM — you want a CRM that knows your sales process, your terminology, your custom fields, and integrates with the three other systems you actually use. The SaaS will give you 60% fit and ten configuration screens you have to maintain. Custom will give you 100% fit and zero configuration screens.
You’re going to grow into the cost. If you’re going to be at 100+ seats in two years, the SaaS subscription is going to be a six-figure annual line item. Custom software is roughly the same one-time cost regardless of seat count, and the only ongoing cost is maintenance — typically 10–20% of the original build per year.
Three questions to ask
When you’re weighing build vs. buy, three questions cut to the answer most of the time:
-
How specific is this workflow to our business? If you can describe it in a sentence and a competitor would recognize the workflow, buy. If it takes a paragraph and three diagrams to explain, build.
-
What does this look like at 5x our current team size? If buying scales linearly with seats and the workflow is going to be load-bearing, the math probably tips toward custom in 18 months.
-
What happens when the vendor changes their pricing or their product direction? If your business breaks when they pivot, you’ve outsourced a load-bearing decision to someone whose interests don’t fully align with yours.
The right answer for most teams is still a mix — buy the commodity stuff, build the custom stuff. But the line between the two has moved. If you haven’t reconsidered the build-or-buy question in 18 months, it’s probably worth the half-hour conversation.