Three Different Answers to One Business Problem
When a workflow breaks, leaders often jump directly to a product search or a custom-build conversation. A third option—automating the handoffs among systems already in place—may be more appropriate than either.
Buying provides established capability and shared product investment. Automating preserves existing systems while removing repeated movement and coordination. Building creates software around a business-specific workflow when available products cannot express what matters.
The decision should begin with the operating requirement, not a preferred technology. Define the outcome, volume, users, data, exceptions, controls, and measures before comparing solutions. Otherwise each vendor or builder will answer a different version of the problem.
Why Companies Make the Wrong Comparison
Purchase prices are compared with development estimates while configuration, integration, data cleanup, training, support, and process change are ignored. Automation is treated as free glue, and custom software is treated either as unlimited flexibility or unlimited risk.
The comparison also becomes distorted when the current workflow remains undefined. A company may buy a feature-rich platform, then reproduce its old spreadsheets and inboxes around the new product because nobody decided how work should move.
A fair comparison uses the same time horizon, required outcome, operating volume, service level, security expectation, and labor assumptions for every option. It includes the cost of keeping the current process as the baseline.
The Six Questions in the Decision Model
| Decision Factor | Question |
|---|---|
| Process Stability | Are the normal path and exceptions understood? |
| Differentiation | Does the workflow create a meaningful competitive advantage? |
| Market Fit | Does a credible product already solve most of the requirement? |
| Integration Depth | How many systems and authoritative records must participate? |
| Control Need | How specific are permissions, approvals, data boundaries, and audit needs? |
| Total Operating Cost | What will ownership require over three years? |
Answer every question with evidence and uncertainty. A decision model cannot eliminate judgment, but it can prevent a familiar product name or exciting prototype from substituting for it.
When Buying Is Usually the Strongest Choice
Buy when the workflow is common, the product market is mature, and the business does not gain meaningful advantage from owning a distinctive implementation. Payroll, basic accounting, commodity scheduling, and standard collaboration often fit this pattern.
The product still needs to satisfy required integrations, data rights, export capability, security, and operating controls. “The feature exists” is not enough if employees must duplicate work around it or the organization cannot retrieve its own information.
Buying becomes weaker when the required workflow is buried beneath expensive unused features, pricing grows sharply with volume, essential data is trapped, or the product forces a process that conflicts with how the business creates value.
When Automation Across Existing Systems Fits
Automate when current systems perform their individual jobs adequately but people repeatedly carry information, status, reminders, or documents between them. The intervention may capture an event, validate data, route work, create a record, notify an owner, and watch for completion.
This option is strongest when APIs or reliable integration surfaces exist and each system has a clear authoritative role. It is weaker when automation would depend on fragile screen manipulation or when no system contains trustworthy source data.
Automation should not conceal a broken process. Remove unnecessary steps and define ownership first. Otherwise the integration preserves confusion at machine speed and makes the resulting failure harder to see.
When a Focused Custom Build Is Justified
Build when the workflow is strategically important, stable enough to define, and poorly served by available products. Custom development is also justified when required control, integration, data boundaries, or customer experience cannot be achieved through reasonable configuration.
The best custom first release is narrow. It should complete one valuable operating job, use existing authoritative systems where sensible, and avoid recreating commodity capabilities that mature products already provide.
Custom ownership includes testing, security, hosting, support, maintenance, and future change. The decision is sound only when the value of fit and control exceeds those continuing obligations—not merely when the first prototype looks persuasive.
A Worked Decision for Service Intake
Consider a regional service company whose website, telephone system, scheduling product, and customer database do not share a reliable intake queue. Buying a new enterprise platform would replace systems employees otherwise use successfully and add significant migration work.
A complete custom operating platform would provide control but duplicate scheduling and customer-record functions. A focused automation layer can instead capture inquiries, validate required information, create or match the customer record, route the request, acknowledge receipt, and escalate aging items.
In this illustrative case, automation wins because the process is stable, existing systems remain authoritative, and the distinctive need is the handoff between them. If later evidence shows the integration surfaces cannot support reliable control, the decision can shift toward a focused build.
Compare Total Cost on the Same Horizon
Include internal employee time at a realistic loaded cost. Include the work that remains after implementation, not only the work the solution claims to remove. Estimate switching and data-extraction cost because it affects future control.
Do not present an uncertain number as a single precise total. Use a defensible range and identify which assumptions could change the decision. The purpose is to expose the economic shape of each option, not to manufacture certainty before discovery.
Make the Decision Reversible Where Possible
Run a bounded proof against real workflow data before committing to the broadest option. Confirm that the product can handle the critical exception, that the integration is reliable, or that the custom interface produces the intended operating outcome.
Preserve access to business data and define an exit path. Avoid irreversible migration, long commitments, or broad custom scope until the highest-risk assumptions have been tested.
A practical decision memo can fit on one page: required outcome, baseline cost, six decision factors, options considered, three-year cost range, critical assumptions, first release, success measures, and stop conditions. That record makes future review possible when volume, products, or business priorities change.
Sources, Methodology, and Limits
The six-question model and three-year cost formula are original SynHy decision tools. They are designed to produce a comparable operating analysis, not a universal recommendation or procurement guarantee.
Current labor assumptions can be grounded in the U.S. Bureau of Labor Statistics Occupational Employment and Wage Statistics. For AI-enabled options, NIST’s AI Risk Management Framework provides voluntary guidance for incorporating trustworthiness considerations throughout design, development, deployment, use, and evaluation.
Sources: BLS Occupational Employment and Wage Statistics; NIST AI Risk Management Framework. Every real decision should use actual product terms, implementation proposals, data rights, workflow evidence, legal requirements, and internal operating costs.