The decision usually arrives framed as build or buy, and that framing eliminates the two options that most often turn out to be correct. Integrating what you already own and consolidating what has accumulated are both cheaper than either alternative and both get skipped because neither involves acquiring anything new.
The Four Options
- BuyAdopt a product built for this problem. Fastest to value. You inherit the vendor's assumptions about how the work should be done.
- IntegrateConnect systems you already run so the process flows between them. Lower cost than it appears, and usually the option nobody scoped.
- ConsolidateRemove tools rather than add one, moving the work into a platform you already own and underuse. Often the highest return and the least popular.
- BuildCreate something specific to your process. Justified when the process is genuinely distinctive and central to how you compete or deliver.
The Question That Decides It
Before evaluating any option, establish how distinctive the underlying process actually is.
Most processes that feel unique are conventional processes with accumulated local variation. Intake, approvals, scheduling, reporting, case management: the shape is common across thousands of organizations even when the details differ. Where that is true, buying is almost always correct, and the variations that feel essential are usually habits rather than requirements.
Where a process genuinely is distinctive, and where it is central to how the organization delivers value, building becomes defensible. That combination is rarer than it feels from the inside.
Distinctive and central justifies building. Distinctive but peripheral is usually a habit worth abandoning.
Working Through the Decision
Most organizations run productivity and cloud platforms whose capabilities are used at a fraction of what is licensed. Before evaluating a new purchase, establish what the existing stack covers. This question alone resolves a meaningful share of platform decisions.
Replacing a platform to fix an unclear process produces a new platform and the same problem, plus a migration. If nobody can describe the current process cleanly, that is the work to do first.
Integration cost scales with connection count and is consistently underestimated. A product that is a strong fit in isolation and connects to nothing you run is often a worse outcome than a weaker product that connects cleanly.
First-year pricing is negotiated. Renewal pricing, per-seat growth, storage overages, and the modules that turn out to be separately licensed are where the real number lives. Ask for year-two and year-three figures in writing before deciding.
Ask the question during evaluation, when you have leverage, rather than during an exit, when you have none. A vendor who cannot describe a clean export path has told you something about the relationship.
Every platform needs an owner responsible for configuration, access, and the decisions that accumulate after launch. A platform without a named owner drifts, and the drift shows up two years later as a system nobody quite understands.
The Cost That Gets Missed
Platform decisions are usually evaluated on license cost and implementation effort. The larger number is what the choice costs in flexibility.
Every platform encodes assumptions about how work should be done. Adopting one means adopting those assumptions, and changing them later ranges from expensive to impossible. That is fine when the assumptions match how you operate. It is a slow problem when they do not, because the organization gradually reshapes itself around the tool rather than the other way around.
Ask the vendor how customers typically handle the two or three parts of your process that do not match their model. If the answer is that customers change their process, decide now whether you are willing to.
A Note on Building
Building is not primarily a development decision. It is a commitment to maintain something indefinitely: security updates, dependency upgrades, changes as requirements shift, and the knowledge of how it works staying inside the organization.
Organizations that build successfully treat that ongoing commitment as part of the cost from the beginning. Organizations that regret building usually scoped the initial delivery and not the decade after it.
Before scoping any platform decision, inventory what the organization already licenses and what portion of it is actually in use. That inventory changes the shape of the decision more often than it does not.