Choose off-the-shelf software when an existing product can support your essential workflow with acceptable constraints. Consider configuration and integration when the product fits most of the work but needs connected systems or tailored rules. Consider a custom build when a necessary requirement remains unmet and you can support the development and ongoing ownership it requires.
The decision should follow evidence about your work, rather than the length of a feature list. This guide gives business owners and operations teams a way to compare the same first release across all three routes. It includes an evidence checklist, an illustrative scenario and a fillable software project brief (PDF).
Compare buying, configuring and building
These routes can overlap. You might buy a system of record, configure its approval process and build a small integration around it. The useful question is which parts need to be different, and who will own those differences.
| Route | A reasonable starting point when... | What still needs proving |
|---|---|---|
| Buy an existing product | The required work is supported by a product and your team can use its operating model. | Fit with real exceptions, permissions, migration, integrations, subscription terms and export needs. |
| Configure and integrate | The core product fits, but rules, forms or handoffs need adjustment within supported capabilities. | Configuration limits, connector access, testing, change management and ownership of each connection. |
| Build custom software | A necessary workflow cannot be met acceptably through the available products or configuration. | A bounded scope, technical feasibility, acceptance criteria, delivery capacity and a credible operating plan. |
Custom development does not remove dependencies: hosting, libraries, interfaces and the people maintaining the system still matter. AWS's discussion of the build-or-buy decision describes combining purchased components with differentiated development and considering the opportunity cost of engineering effort. That is a useful framing, not a reason to assume a custom or cloud solution is always preferable.
Define requirements that cannot be traded away
Start with one complete workflow: its trigger, users, decisions, exceptions and finish. Separate what the business needs from the way the current tool happens to implement it. A familiar screen layout may be a preference; the ability to prevent an unauthorized approval may be essential.
Write each mandatory requirement as something a reviewer can observe. For example, "connects to our CRM" is too broad. "An approved request transfers its reference ID and agreed fields, and a failed transfer stays visible for review" gives a supplier something specific to demonstrate.
- Workflow: Which normal case and important exception must the first release handle?
- Data: Which system holds the authoritative record, and what must be imported or exported?
- Access: Which roles can view, change, approve or export each type of record?
- Operation: Who handles failed work, updates, monitoring and user support?
- Constraints: Which actual deadlines, budget limits and applicable security requirements must the decision respect?
A candidate that fails a mandatory requirement needs a workable remedy or a narrower scope. Do not let attractive optional features average away that failure. If a requirement is still uncertain, mark it unproven and define the evidence needed.
The UK government's guidance on commercial off-the-shelf products recommends understanding the problem and testing options before committing, while considering the whole service. This is a helpful planning example; it is not a procurement rule imposed on US private businesses.
Ask every candidate to demonstrate the same cases
Use sanitized examples that represent the work, including a difficult case. Ask who performed the demonstration, which product version and license it used, and which assumptions would change in your environment. A proposal saying a feature can be built is not the same as a working demonstration.
The table below is an original planning aid, not a validated scoring model. For each row, record demonstrated, unproven or blocked, then add a reviewer and next action. Apply it to a product, configured prototype or custom prototype with the same standards.
| Criterion | Evidence to request | Decision note to capture |
|---|---|---|
| Workflow fit | Complete one normal case and one important exception. | What manual work or workaround remains? |
| Integration | Transfer the required fields; demonstrate a failure and a safe retry. | Which interface, entitlement, volume limit and owner apply? |
| Permissions | Test an allowed action and a denied action with representative roles. | Who reviews access and can change it? |
| Changeability | Explain and, where practical, demonstrate one expected business-rule change. | Who implements, tests and approves the change? |
| Operation | Walk through monitoring, support, updates and recovery. | Are responsibilities and support arrangements defined? |
| Exit | Export representative data, including needed relationships or attachments. | What can be reused, and what migration work remains? |
A connector in a catalog does not establish that your integration will meet its workload. For example, Microsoft's Power Automate limits documentation describes license-dependent profiles and connector limits; failures, retries and pagination can also contribute to request usage. Check the current documentation and terms for the actual platform being evaluated instead of assuming an advertised connection covers every case.
If the issue is primarily a handoff between otherwise adequate tools, explore API integration before assuming that both systems must be replaced. If AI is proposed for part of the work, use the AI readiness checklist to define the data, human review and evaluation that step needs.
Compare the whole ownership commitment
Compare the same scope over the same planning period. Ask each supplier to show what is included, excluded, recurring and uncertain. An initial build estimate and one month of a product subscription are not equivalent cost comparisons.
- Initial work: discovery, configuration or development, integration, migration, testing, training and internal staff time.
- Ongoing work: licenses, hosting, usage charges, monitoring, maintenance, support and retained human review.
- Change: expected business-rule changes, upgrades, retesting and dependencies on a supplier's roadmap.
- Exit: data extraction, documentation, transition work and the access or rights needed to operate a replacement.
For custom work, define source-code access, accounts, documentation and ownership terms in the agreement. Buying software also requires an operating owner: someone still needs to administer users, resolve exceptions and manage changes. Ask what your team must supply for each route, including time taken away from other work.
Use the automation ROI worksheet when comparing handling effort and operating cost. Keep released staff capacity separate from actual cash savings, and include the human work that remains. This guide does not supply vendor prices, delivery estimates or a guaranteed payback.
Apply the framework to one request workflow
This example is hypothetical, not a Midwest Digital client result. A service business approves requests in a CRM and passes approved records to a scheduling system. It needs a traceable reference ID, a reviewer for exceptions and a way to prevent duplicate destination records when a transfer is retried.
Buying may fit if a product's supported workflow demonstrates those requirements with acceptable permissions and export access. The next step is to validate migration and operating responsibilities, rather than commissioning an alternative merely because it can be customized.
Configuration plus integration may fit if the CRM and scheduling tool already serve their users well, but the handoff is manual. A bounded trial can establish field mapping, access, duplicate prevention and visible recovery when one system is unavailable.
Custom development becomes a candidate if a necessary approval or scheduling rule cannot be supported acceptably by the tested options. That finding is not a finished business case. The team still needs a feasible first release, acceptance tests, an owner for support and a comparable cost view.
In all three cases, test the same acceptance statement: given an approved request with an agreed reference ID, a retry must not create an unintended duplicate; if the destination is unavailable, pending work remains visible to its owner. Agree exactly how the system should behave and what evidence will count before the trial.
Write the decision and the next test
Keep a short decision record: the workflow and users, mandatory requirements, candidates tested, observed evidence, unresolved questions and why the preferred route is reasonable. Name the person who can approve scope and the person who will own the system after launch. Record what new evidence would change the decision.
Download the fillable software project brief (PDF, 3 pages) to document the scope, connections, acceptance cases and responsibilities. Use short answers in its 21 fields or print it; continue longer notes in your project document. Keep passwords, API keys and personal customer records out of material you share.
For a scoping conversation, bring the completed brief, a sanitized example, your current systems and the requirements that remain unproven. Midwest Digital's custom software services cover discovery, architecture, development, integration, testing and support. Discuss your project or call 469-468-2480 to work through a practical next step.