The real question
Build vs buy sounds like a technology preference but is really a fit question: how closely does the workflow match what a platform already does, and how much does bending the workflow to the platform cost in outcomes? Standard flows — approvals, form routing, simple integrations between mainstream SaaS tools — match platforms well. Unusual flows, deep integrations and judgement-heavy steps match them poorly.
The second half of the question is time horizon. Platform pricing is a permanent operating cost that scales with usage; engineered automation concentrates cost early and then declines to support and iteration. Which shape is better depends on volume growth and how long the workflow will live.
Where platforms fit
No-code and low-code platforms shine at speed for standard patterns: connecting popular SaaS tools, routing approvals, syncing records and giving operations teams direct control over simple flows without an engineering queue. For a team automating its first commodity workflows, a platform is often the right first step.
The limits appear at the edges: connectors that cover eighty percent of a system's API, logic that outgrows visual builders, per-task pricing that compounds with volume, and flows so numerous that the platform itself becomes an unmanaged system needing governance.
Where engineered automation fits
Engineered automation — custom integrations, orchestration, RPA and AI components built for the workflow — fits when the workflow is specific to the business, touches systems without good connectors, needs controls a platform cannot express, or runs at volumes where per-task pricing stops making sense.
It also fits when the workflow is the competitive edge. Encoding a differentiated operation into the same platform template competitors use flattens the differentiation; owning the logic keeps it.
Cost shape over time
Platforms price as subscriptions plus usage: attractive entry, then a line that grows with adoption and never ends. Engineered automation prices as a build plus a support model: a larger first number, then maintenance that stays roughly flat as volume grows.
The honest comparison runs both shapes over the workflow's expected life at expected volumes. High-volume, long-lived workflows usually favour building; low-volume or experimental workflows usually favour buying until the pattern proves out.
Lock-in and exit
Every buy decision is also an exit decision. Logic, history and integrations encoded in a proprietary platform migrate with difficulty; when pricing changes or the vendor pivots, the switching cost is the negotiation lever you handed over. Owned code and open tooling keep that lever.
Lock-in is acceptable when the platform's value clearly exceeds it, and dangerous when it accumulates silently across dozens of small flows that nobody could rebuild from documentation.
The combined pattern
The stable end-state in most enterprises is a mix. Commodity flows live on a platform under sensible governance. Workflows that are high-volume, integration-deep or differentiating are engineered and owned. The boundary is reviewed as volumes and pricing evolve.
The failure modes are the extremes: rebuilding what a platform does perfectly well, or forcing a differentiated operation through a template because the licence was already paid.
Build vs buy at a glance
| Dimension | Platform (buy) | Engineered (build) |
|---|
| Best fit | Standard flows between mainstream tools | Specific, integration-heavy or differentiating flows |
|---|
| Entry cost | Low; subscription starts immediately | Higher; scoped build precedes value |
|---|
| Cost over time | Grows with seats, tasks and volume | Roughly flat support after the build |
|---|
| Control depth | What the platform exposes | Whatever the workflow requires |
|---|
| Lock-in | Logic and history live in the vendor | Logic and history are owned |
|---|
| Speed to first value | Days for simple flows | Weeks for a scoped first release |
|---|
