Most "build vs. buy" debates are won by whoever is in the room with the loudest opinion. That's a bad way to make a five- or six-figure decision. Here's the framework we use with clients when they're weighing custom software development against an off-the-shelf product.
Start with the workflow, not the feature list
Feature checklists lie. Two products can both "do invoicing" and be completely different in how they handle the one edge case that defines your business. Instead of comparing features, write down the three or four workflows that actually make you money or save you the most time. Then ask: does the off-the-shelf tool let me run my workflow, or does it force me to run its workflow?
If the answer is "we'd change how we work to fit the tool," that's fine for commodity processes — payroll, email, accounting. It's expensive for the processes that are your actual edge.
The honest case for buying
We tell clients to buy off-the-shelf when:
- The process is a commodity (HR, expense reports, CRM basics).
- A mature product already models the domain well.
- Your volume is low enough that the tool's limits won't bite for years.
- You don't want to own the maintenance, security, and uptime.
Buying is almost always cheaper in year one. The question is whether it stays cheaper.
The honest case for building
Custom software earns its cost when:
- The workflow is your differentiator and no product fits it.
- You're stitching together three or four systems that don't talk to each other.
- Per-seat or per-transaction SaaS pricing is about to scale past the cost of building.
- You keep paying for "integrations" and "workarounds" that almost work.
The most expensive software is the off-the-shelf tool you've bent so far out of shape that nobody can explain how it works anymore.
The middle path most people miss
It's rarely all-or-nothing. The strongest architectures buy the commodity layers and build only the thin slice that's genuinely yours — a custom workflow on top of bought infrastructure, integrated cleanly. That's where domain modelling pays for itself: you build the 20% that matters and let proven products carry the rest.
A quick gut check
If you can't name the specific workflow that off-the-shelf software breaks, you probably don't need custom software yet. If you can name it in one sentence — and you've already paid for two failed workarounds — you probably do.
When you want a second opinion that isn't selling you a license or a build, that's exactly what a software consulting session is for. We'll tell you which way to go, even when the answer is "don't hire us, buy the product."