The wrong technology decision usually starts one step too late. Teams compare products, development estimates, or AI demos before agreeing on the workflow they are trying to improve. That turns a business decision into a feature contest.
Start with the operation: who initiates the work, what information is required, where decisions happen, which exceptions consume senior attention, and what outcome the business needs to measure. Once that map is clear, the build-versus-buy question becomes much less subjective.
The four signals that determine the path
1. How standard is the workflow?
If competitors can run the same process in roughly the same way, a mature product is usually the strongest starting point. Accounting, payroll, commodity scheduling, and basic CRM often belong here. Customizing a standard process can create maintenance cost without creating advantage.
2. Where does complexity actually live?
A process may look standard until the handoffs begin. Pricing rules, customer promises, field exceptions, approvals, collections, and cross-system reconciliation are often where the real operation lives. If people maintain private spreadsheets and inbox rules to bridge those gaps, the business has already created custom software—just in a fragile form. See the six signals that spreadsheets have become an operational risk.
3. Is the workflow stable enough to encode?
Automation scales repetition, including bad repetition. If the team cannot agree on the states, owners, and exception rules, automating immediately will make ambiguity move faster. First simplify the process; then encode it.
4. Does better execution create business advantage?
Custom investment is easier to justify when the workflow directly affects response time, capacity, collection speed, customer visibility, quality, or margin. The question is not whether software can be built. It is whether owning this operating capability improves the business enough to deserve ongoing stewardship.
A practical decision table
| Choose | When it fits | Main risk |
|---|---|---|
| Buy | The process is common, requirements are well served, and adoption is cheaper than differentiation. | Forcing important exceptions into rigid product assumptions. |
| Automate | The tools are acceptable, but people repeatedly move information or trigger the next step by hand. | Building brittle connections around an unclear process. |
| Build | The workflow is distinctive, exception-heavy, or central to how the company serves customers and manages operations. | Creating a large platform before proving the smallest valuable slice. |
| Add AI | The role involves reading context, drafting, classifying, summarizing, or choosing among bounded actions with observable outcomes. | Giving probabilistic behavior authority without evaluation, monitoring, or human escalation. |
Compare three approaches to the same purchase request
For this illustrative scenario, a branch requests supplies, a manager approves the request and purchasing issues one order. The team must also handle an unavailable supplier. Test each option against that same path before comparing a product subscription with a development quote.
| Approach | What to demonstrate | When this is enough |
|---|---|---|
| Buy an existing product | Configure branches, approval roles and the supplier exception using supported settings. | The normal path and important exceptions work, and staff can adopt the process without costly workarounds. |
| Connect the tools you use | Transfer an approved request to purchasing, preserve its reference and show a failed transfer to an owner. | The current tools already handle approvals and purchasing well; the missing piece is the handoff. |
| Build a focused workflow layer | Keep the existing accounting system while building the branch rules, exception handling and shared working view. | Important operating rules cannot be supported adequately by the available products or connections, and the team can own ongoing maintenance. |
If an existing product passes the agreed cases, buying it may be the better decision. A custom build needs a specific gap to justify its cost. Also test a changed approval and a cancelled request: the preferred option should remain understandable when the original plan changes.
A related example from our work: NovaPro
We built NovaPro as a procurement management platform connecting suppliers, quotations, purchase orders, inventory and projects. It is an example of a shared operational system in our portfolio. The branch approval scenario above is illustrative; it is not a claim about NovaPro's exact rules, savings or implementation cost.
See what we built for NovaPro →
Do not choose a single answer for the whole operation
The strongest architecture is often a combination. Keep the accounting platform. Automate the transfer of approved operational data. Build the workflow layer that reflects how teams actually coordinate. Add an AI role to read incoming context and prepare the next action, while keeping approval with the employee who owns the outcome.
This layered approach protects the value of proven products without allowing their boundaries to dictate the entire operation. It also creates a smaller, clearer custom scope.
What should the first investment include?
- A workflow map: states, owners, inputs, decisions, exceptions, and measurable outcomes.
- A thin operational slice: one path that removes a real bottleneck end to end.
- Integration boundaries: which systems remain authoritative and what data moves between them.
- Operational controls: permissions, auditability, failure handling, and a clear owner after launch.
- A measurement plan: baseline cycle time, manual touches, exceptions, and outcome quality before claiming improvement.
Security and AI risk belong in the decision—not after it
Custom does not mean improvised. NIST's Secure Software Development Framework recommends integrating secure practices into the development lifecycle rather than treating security as a final review. For AI-enabled workflows, NIST's AI Risk Management Framework organizes work around governing, mapping, measuring, and managing risk. In practical terms: define what the AI may do, test it against realistic cases, log actions, restrict tool access, and make escalation part of the workflow.
The AgenticShip rule
Buy the commodity. Automate the stable handoff. Build the operating advantage. Use AI for bounded work where context matters—and keep the outcome observable.
If the answer is still unclear, do not begin with a platform roadmap. Begin with one process, one costly bottleneck, and one measurable outcome. That is enough to determine the right technology path.