The build-versus-buy conversation usually ends with a general answer: for most functions, buy. For the handful where buy is wrong, build. The honest question is which functions fall into that second category, and why.
We wrote a longer piece on the full framework for that decision in Build vs. Buy: Custom Software vs. SaaS. This article is a companion. It looks specifically at the six workload patterns where, across our engagements, custom software has a durable edge over SaaS. Not a marginal edge. Not an edge that depends on clever procurement. A durable edge that compounds over time.
If a function in your organization matches one of these patterns, the buy decision is almost certainly wrong. If it does not, the reverse is usually true.
Pattern 1: The workflow is the differentiator
Some workflows are operational plumbing. Running payroll. Processing expense reports. Managing office supply orders. These are the same in every company, and doing them differently does not help the business win.
Other workflows are the business. How an insurance company routes claims for specialist review. How a logistics company dispatches vehicles based on a proprietary optimization model. How a trading desk structures a bespoke derivative. In these cases, the workflow is not a process the company has to do. The workflow is what the company sells.
SaaS cannot support a differentiating workflow. If it did, the SaaS would sell the same workflow to a competitor, and the differentiation would evaporate. Vendors know this, and their products are deliberately configured to represent industry-standard practice. The moment you try to encode genuine competitive advantage into a SaaS workflow engine, you are fighting the product. Every customization is a fight. Every upgrade might break it. And the vendor is not on your side when the fight matters.
If the function is how the business wins, custom is correct.
Pattern 2: The data must stay inside organizational boundaries
Some data, by regulation or by strategic preference, cannot leave the organization. Patient records in jurisdictions with strict data residency. Trade secrets that represent years of R&D. Customer data in industries where a vendor breach would end the business. Model training data that encodes the company’s actual intellectual edge.
SaaS by definition involves shipping data to a third party. The contractual protections are real but imperfect. The breach history of SaaS vendors is also real, and the trend is not improving. For data where the downside of a vendor breach is existential, the correct architecture is one where the data never crosses the boundary in the first place.
This does not mean every workload involving sensitive data must be custom. It means the specific systems that operate directly on the data — the ones with the broadest and deepest access — benefit from being built and controlled internally. Peripheral systems can usually be SaaS.
Pattern 3: Integration requirements exceed what any SaaS exposes
Every SaaS exposes an API. Few expose the access patterns a specific customer actually needs. The API is designed for the common case. It returns the fields the vendor chose to expose, at the throughput the vendor chose to allow, with the event model the vendor chose to build.
When your integration needs are close to the common case, this is fine. When your integration needs require joining data that the SaaS does not expose, or subscribing to events the SaaS does not publish, or reading at throughput the SaaS rate-limits, the gap is permanent. You cannot fix it by asking the vendor nicely. You cannot fix it by paying more. You can only fix it by working around the API — at which point you are maintaining a brittle integration layer that breaks every time the vendor ships an update.
If the integration surface you need does not exist in any SaaS product, and is unlikely to, custom is correct.
Pattern 4: Domain-specific UX where generic tools create friction at every step
Generic tools are built to be useful to many users, which means they cannot be optimal for any specific user. For most functions, this is a reasonable trade-off. The team adapts to the tool, and the time lost to slightly-wrong ergonomics is small enough to ignore.
For some functions, it is not. Consider a radiologist reading two hundred scans a day. Consider a dispatcher routing three hundred vehicles in real time. Consider a trader managing hundreds of open positions across multiple instruments. In these cases, the difference between an interface optimized for the exact workflow and a generic interface is not a small loss. It is a meaningful fraction of the operator’s capacity, multiplied by every hour of every workday.
If the users of a system are specialists performing high-volume domain-specific work, and generic tooling creates friction at every step, the UX itself becomes the case for custom. The cost of the custom build is paid back in operator productivity within the first year.
Pattern 5: The SaaS cost curve grows faster than the business needs grow
Many SaaS products price on usage — per seat, per event, per transaction, per gigabyte. When usage is small, the pricing feels reasonable. When usage scales, the pricing grows linearly or sometimes superlinearly, while the actual marginal cost to the vendor is near zero and the actual value to the customer does not scale at the same rate.
Custom software has a different cost curve. A large upfront investment, followed by fixed maintenance cost that does not grow with usage. Past a certain volume, the custom curve crosses below the SaaS curve and stays there for the life of the system.
The volume at which this crossover happens depends on the specific SaaS pricing and the specific build cost, but we see it consistently in a few categories: high-volume customer messaging, high-throughput data processing, large-scale analytics, and any per-user product where the seat count grows by hundreds per year. If your usage is on a growth trajectory that will make SaaS cost a multi-million-dollar line within three years, custom is worth serious consideration now.
Pattern 6: Regulatory requirements no vendor satisfies cleanly
Some regulated functions have SaaS options that satisfy the letter of the regulation. Some do not. The gap usually appears in industries with region-specific rules that do not align with the major vendors’ deployment footprints, or in use cases where the audit requirements exceed what any vendor can provide.
Signs you are in this pattern: the SaaS options you have evaluated all require a compensating control that adds complexity to your operations; your regulatory counsel is uncomfortable with vendor attestations and wants direct evidence; the audit trails the vendor provides do not capture the fields your regulators ask about; the data processing agreements the vendor offers require redlines the vendor will not accept.
When these signs are present, the cost of making a SaaS work in a regulated context can exceed the cost of building what the regulation actually requires. Custom is not a workaround in these cases. It is the shortest path to compliance.
The patterns in combination
Most custom software projects that succeed in the long run match more than one of these patterns. A differentiated workflow that also processes sensitive data. A domain-specific UX that also requires integration access no SaaS provides. A cost curve that is growing and also subject to regulatory constraint.
Projects that match only one pattern are sometimes better off solved with aggressive customization of a SaaS, rather than a full custom build. The cost of building and maintaining software is real, and the decision should not be taken lightly because a single pattern is present.
Projects that match none of these patterns should almost always be solved with SaaS. Building in those categories is an expensive way to reinvent something a vendor already does well.
A simple test
Before committing to a custom build, run the candidate function through the following questions.
- Is this function how the business differentiates, or is it table stakes?
- If a vendor breach exposed all the data this function touches, would the business survive?
- Do any SaaS products expose the exact integration surface needed, or will we need to work around the API?
- Do the users of this function spend a meaningful part of their day inside it, performing specialized work?
- On a three-year projection, does the SaaS cost curve grow faster than the business value grows?
- Are there regulatory or compliance requirements that no vendor satisfies without compensating controls?
Three or more honest yeses, and custom is probably the correct answer. Zero or one, and SaaS almost certainly is. Between those extremes is where judgment matters most — and where an outside perspective often pays for itself.
The full decision framework for the broader question lives in our pillar piece, Build vs. Buy: Custom Software vs. SaaS, which walks through the lifecycle cost model and the reversibility test that usually settles the close calls.
Top comments (0)