Build buy or commission is not a coin flip, and it is not a taste preference either. Each path solves a different problem, and most teams pick the wrong one for reasons that have nothing to do with the work in front of them. They build because an engineer wants to build. They buy because a vendor had a good demo. They commission because someone heard the word “custom” and panicked. The right answer depends on three things: how core the process is to the business, how big the team maintaining it will be, and what the budget actually covers once you include the years after launch, not just the launch itself.
Build buy or commission: build it yourself only if it is core and you can staff it
Building in-house makes sense when the process is close to your competitive edge and you have engineers who will still be there in a year. If the workflow is something a competitor could replicate by buying the same SaaS tool you would have bought, building it yourself is usually wasted effort dressed up as ownership. Building only pays off when the logic is specific to how your business actually works, and when the team that builds it is also the team that will carry the maintenance bill afterward. That bill runs 20 to 30 percent of the original build cost every year, in models that change, APIs that deprecate, and schemas that drift. If nobody on staff is budgeted for that ongoing cost, the build is already a liability before it ships.
Buy off the shelf when the process is common
Buying is the right default when the process you are automating is not unique to you, just inconvenient. Invoicing, scheduling, basic reporting, standard CRM workflows: thousands of companies have the same problem, and a vendor has already amortized the cost of solving it well. The trap with buying is assuming the vendor’s “agent” label means what you think it means. A lot of what is sold as an agent is a fixed pipeline with a model bolted on for the demo, and the agent or workflow test takes about ten minutes to tell you which one you are actually paying for. Before signing anything, run through the questions to ask before you buy automation: they surface the failure modes a sales call will never mention, including what happens when the tool breaks at 2am and nobody on your side knows why.
Commission a specialist when the process is yours but the team isn’t
Commissioning sits between the other two: it is for processes specific enough that no off-the-shelf tool fits, but not core enough to justify hiring and keeping engineers to maintain a build forever. This is the right call for a two to fifteen person company with one genuinely unusual workflow and no engineering bench. You get something fitted to your actual process without carrying permanent headcount for it. The risk is the opposite of the buy trap: you hand someone a broken process and ask them to automate it, which just makes the dysfunction move faster. A good consultant will push back and insist on fixing the process before automating it; one who does not is building you a faster way to fail.
How core the process is decides more than the budget does
Budget sets a ceiling, but how core the process is decides which option is even sane to consider. A process that touches your actual differentiation, the thing customers would notice if it got worse, belongs in-house or with a long-term commissioned partner you trust to stick around. A process that is purely operational overhead, the kind every company in your category does the same way, belongs bought. Mistaking an overhead process for a core one gets you an expensive internal build nobody asked for. Mistaking a core process for overhead gets you locked into a vendor’s roadmap for the one thing that was supposed to set you apart.
Team size and budget are constraints, not excuses
A five-person team has no business building when it could buy, and a two-hundred-person team has no business buying a generic tool for its most core workflow. Team size and budget tell you what you can sustain, not what you should want. The honest version of this decision starts with naming how core the process is, then checks whether the team and budget can actually support the option that fits. If they can’t, that’s a signal to shrink the scope of what you’re automating rather than force a mismatched option through anyway.