Buy, Configure, or Build
Every operations software decision now has three answers, and the first problem is that each answer comes with a salesperson attached. Microsoft's own ecosystem runs the identical decision under different names, which I've written about separately: stay, extend, or build. The product vendor says buy. The platform reseller says configure. The development shop says build. Each is sometimes right, and the tell that you're getting advice instead of sales is simple: an advisor worth listening to gives different answers for different workflows. Be suspicious of anyone whose answer never varies.
Here's how I actually make the call, workflow by workflow.
Buy, when the workflow is standard
Off-the-shelf wins when your version of the problem is genuinely like everyone else's version. Accounting, payroll, help desk ticketing, standard CRM: these are solved problems, and buying a solved problem is the right kind of boring.
The test is contortion. If adopting the product means bending your workflow to fit its assumptions, count the bends. A few are the normal price of buying; past that, you're paying subscription fees to work someone else's way, and the "configuration project" to close the gap quietly becomes a second budget. Buy when the product fits the workflow you actually run, not the workflow the demo assumes you run.
Configure, when the platform you own can carry it
The middle path is extending platforms you already pay for: automation flows, scoped agents, connectors, the low-code layer. This is the right zone more often than either salesperson admits, because it's fast, it stays inside licensing and governance you already have, and simple processes genuinely thrive there.
Its boundary is complexity, and the boundary announces itself. Exceptions accumulate. The flow chart stops fitting on one screen. "Except when" starts appearing in every description of how it works. Past that point you're paying custom-application prices for flowchart-tool flexibility, and every future change costs more than it should. Configure the simple version of the workflow; the moment real decision logic arrives, you've crossed into the third zone whether you admit it or not.
Build, when the workflow is your way of operating
Some workflows are your competitive method: the intake process tuned over a decade, the triage logic that encodes judgment nobody wrote down, the chain that crosses three systems because that's how your operation actually runs. Bending those to a product's assumptions costs you the very thing that makes them valuable.
These used to stay manual forever, because building meant a six-figure project and the math never worked for a workflow wasting ten hours a week. That math is gone. AI-powered development tools let a small team ship a focused, custom operations application in weeks, using the same pipeline I run for my own products and for clients. The leaders still pricing "build" with pre-AI numbers are systematically choosing wrong on their most valuable workflows, because the option they're dismissing costs a fraction of what they think it does.
The tiebreakers
When a workflow genuinely sits between zones, three questions settle it:
How particular is your version? Standard problem, buy. Your problem with light connections, configure. Your method, build.
Who has to maintain it? A bought product is maintained by the vendor. A configured flow is maintained by whoever built it, forever, which is fine until they leave. A built application is maintained deliberately, as a product, which is a cost and also the point.
What does the decision logic weigh? If the workflow embeds decisions with real consequences that must run identically every time, that's an application property. Neither a product's generic rules nor a flowchart's branches carry it well past a certain weight.
And one rule that applies in all three zones: none of them absolves you of adoption. A bought tool, a configured flow, and a custom build all stall the same way, through unowned change, unretired old paths, and unmeasured results. Pick the right zone, then run the change like it matters, because the zone was never the hard part.
Sorting a real workflow into its zone usually takes one conversation. If you're staring at one, that conversation is what I do.
Rosemarie Withee has spent thirteen years helping operations teams get real work out of their software, first Microsoft 365, now AI. She’s written six books for Wiley and builds AI products at Portal Integrators.