Build, buy or extend: choosing the right business system
Buy when a standard product fits the work and its constraints. Build when an important business requirement cannot be met sensibly by available products. Extend when the existing system remains useful but a specific workflow, connection or interface is missing. A sound decision can combine all three.
Start with the work that must change
Describe the decision or activity the system must support before making a feature list. Who starts the work? What information do they need? Who can approve a change? What happens when the normal process fails? Separate essential requirements from habits that could reasonably change.
Then identify which requirements are genuinely distinctive. Standard accounting, identity or document functions may suit existing products. A specialised allocation process or approval policy may need something more specific. Treat that as a question to test with real scenarios, rather than an automatic reason to commission custom software.
An illustrative choice: purchasing approvals
Consider a distributor with a functioning accounting package. Purchasing teams circulate spreadsheets because an order may need approval from several departments, depending on its purpose and delivery location. Replacing the accounting system would change far more than the approval problem.
One option is to configure the package's existing approval features. Another is to add a workflow application that sends approved transactions to accounting. A custom system becomes a stronger candidate if those options cannot represent the required decisions without fragile workarounds. Test a routine purchase, a disputed request and an amended order before choosing.
Compare the whole operating commitment
Evaluate each option against the same evidence. A polished demonstration is less useful than seeing your important scenarios handled clearly.
- Business fit: which essential scenarios work directly, need configuration, or require custom code?
- Integration: can the system exchange the right records without repeated manual entry?
- Control: can you manage access, approvals, changes and exceptions at the required level?
- Ownership: who maintains the solution, resolves failures and supports users?
- Exit: can you retrieve usable data and move away without rebuilding the whole operation?
Make the tradeoffs explicit
Buying can reduce the amount of software you maintain, but leaves you dependent on a supplier's roadmap and commercial terms. Building provides more control over behaviour, while making ongoing engineering and support part of your responsibility. Extending can preserve useful investments, but introduces connections that also need testing and ownership.
Compare lifecycle effort as well as the initial quote: configuration, migration, integration, training, support and future changes. Avoid selecting a product on licence price alone or custom software on the appeal of unlimited flexibility.
A useful first step
Prepare a short decision brief with the business outcome, three representative scenarios, essential constraints and the systems that must remain. Ask each proposed approach to demonstrate those same scenarios. Hyperwise can help translate the operation into a system boundary and evaluate where existing platforms, integration and custom engineering belong.