← Back to the blog

Custom software vs SaaS: build or buy?

The build-vs-buy decision isn't really about cost. It's about which parts of your business you're willing to outsource to someone else's roadmap.

Build vs buy is presented as a cost question. It isn't. The cost math almost always favours buying — at least in the first year. That's why so many teams buy and then, three years later, realise they've outsourced the most important part of their product to someone else's roadmap.

The real question

The question worth asking isn't which is cheaper. It's: which parts of this business do we need to control, and which can we rent?

A good off-the-shelf SaaS rents you a feature. A custom build gives you a capability. The difference shows up the day you need the tool to do something the vendor hasn't prioritised.

When to buy

  • Commodity workflows. Email, calendars, payroll, accounting, CRM at small scale. You will not differentiate on these. Buy the best one and move on.
  • Compliance-heavy infrastructure.Identity, payments, document signing. The vendors have spent years on the certifications you don't want to chase.
  • Anything that's a feature, not a strategy.If the tool exists in a Gartner quadrant, it's probably a buy.

When to build

Build when the software isthe product, or when it's the mechanism by which the product wins. Some concrete examples from client work:

  • Pricing engines, when pricing is your competitive edge.
  • Internal tools that staff use 6+ hours a day. The cost of a 10% productivity gain compounds quickly.
  • Data pipelines where the schema is the moat.
  • Customer-facing surfaces where SaaS templates would make you look like everyone else.
HeuristicIf a feature being on a competitor's vendor roadmap would harm your business, don't put it on a vendor's roadmap. Build it.

The hybrid case

Most real systems are hybrid. You buy auth (Auth0, Clerk), you buy payments (Stripe), you buy email delivery (Postmark, Resend), and you build the parts that are actually yours on top. The question is where you draw the line.

Our rule of thumb: rent infrastructure, build product. If a vendor change would be invisible to your users, it's infrastructure — rent it. If a vendor change would force a UX redesign, it's product — build it.

Most of our case studiesare hybrids of exactly this shape. If you're working through a build-vs-buy decision, we do scoping calls for this specifically.

★ ★ ★

End of article · Thanks for reading

Subscribe

More of this, once a month.