Choose off-the-shelf software when an existing product handles the essential workflow and your team can work within its constraints. Consider custom software when a valuable requirement remains unmet after a realistic product trial, and you can fund both delivery and ongoing operation. A hybrid approach often deserves evaluation too: keep established software for standard functions and build the part that is specific to your business.
The decision is not settled by comparing a monthly subscription with a development quote. Compare what each approach actually delivers, what your people must still do manually and how difficult it will be to change direction later.
Start with a task, not a feature inventory
“We need a dashboard” is too vague to guide a purchase. A better requirement is: “An operations manager must see which client jobs are waiting for documents, assign the next action and record who approved the latest version.”
Write three to five tasks that must work end to end. Give each one a sample record, a named user and a pass condition. Add at least one exception: a client uploads the wrong document, a reviewer leaves the company or an integration fails halfway through an update.
This creates a test that a vendor demonstration and a custom prototype can both attempt. It also prevents optional features from outweighing a missing essential action.
Test the work, then choose the approach
Use a representative task and exception.
Run it through a product or prototype.
Record the gaps and their operational cost.
Compare three approaches on the same requirements
| Approach | A sensible fit | What to investigate |
|---|---|---|
| Configure an existing product | Your process is close to supported workflows | Permissions, integration limits, plan restrictions and export quality |
| Build a custom application | Important behaviour cannot be expressed reliably in available products | Delivery scope, operating responsibilities and future maintenance |
| Combine a product with a custom layer | Standard records can stay in an existing tool, but a specific interaction needs improvement | Which system owns each field and how updates are reconciled |
A hybrid solution still needs clear boundaries. For example, the CRM may own contact details while a portal owns document review status. If both can independently overwrite the same status, the integration needs a conflict rule. Without one, the team may simply replace spreadsheet reconciliation with application reconciliation.
GOV.UK's technology guidance emphasizes total ownership cost and preserving future choices. Its public-service context is different from a small business, but those two questions are useful here: can you operate the choice, and can you leave it?
Use a decision worksheet with real evidence
For each candidate, fill in this worksheet after a trial. Treat essential requirements as pass or fail before assigning scores to preferences.
| Criterion | Evidence to collect | Result to record |
|---|---|---|
| Core workflow | Complete a representative job | Pass, fail or workaround required |
| Access rules | Try the same action as different users | Who can see and change each record? |
| Integration | Create, update and retry a test record | Reliable identifiers and documented limits |
| Data exit | Export records, files and relationships | Can another system reconstruct the work? |
| Daily operation | Ask the team to perform its usual tasks | Friction, training and manual steps |
| Support | Review response arrangements and responsibilities | Named owner and escalation route |
If scoring helps compare candidates that pass the essentials, choose weights before the trial. A team might give workflow fit 35%, operating cost 25%, integration 20% and changeability 20%. Those are illustrative priorities, not a validated scoring standard. A high weighted score must never excuse a failed mandatory requirement.
Evidence beats feature counts
Reject an option that fails a mandatory requirement.
Test identifiers, updates and failure recovery.
Account for support, changes and data exit.
Compare ownership cost over a stated period
Build a worksheet for the same time horizon and workload. Include implementation, migration, training, licences, hosting, support, internal administration, expected changes and exit work.
For a deliberately simplified 24-month example, imagine a configured product costs $2,400 to set up, $300 per month in subscriptions and $150 per month in internal administration. The total is $2,400 + 24 × ($300 + $150), or $13,200.
Imagine a custom option costs $12,000 to build, $80 per month to host and $350 per month to maintain. Its total is $12,000 + 24 × ($80 + $350), or $22,320. All figures are invented USD assumptions, not actual quotes or market rates. They omit taxes, financing and any costs not listed.
These numbers do not establish a winner. The custom option might address a requirement the product cannot meet; the product might already deliver everything necessary. First confirm functional comparability. Then test the model against higher user counts, support demand and change requests. Do not add a speculative “competitive advantage” amount merely to make one option win.
The automation cost guide explains how to separate implementation, recurring services and internal effort for a connected workflow.
Know when adapting your process is the better choice
An existing process is not automatically a valuable differentiator. A complicated approval chain may be a historical accident rather than a requirement worth rebuilding in software.
If a product offers a simpler approach that preserves accountability and meets the business need, changing the process may be preferable. Ask the people doing the work to try it on real examples. Equally, do not force an essential requirement into notes fields and manual reminders simply because the licence has already been purchased.
Custom development deserves serious consideration when the unmet requirement has a clear owner, measurable operational consequence and stable enough rules to implement. If those are still uncertain, prototype the risky step before commissioning an entire application.
Keep standard parts; build the specific part
Keep established records and standard functions.
Assign a source of truth for each shared field.
Implement the interaction the team actually needs.
Plan for the day somebody else maintains it
For a purchased system, check export formats, account ownership, integration access and the process for moving away. For custom software, agree repository access, deployment instructions, dependency documentation, backup recovery and responsibility for security updates. Verify the ownership and licence terms in the actual agreement rather than assuming that “custom” means unlimited rights to every component.
If clients need to participate, the portal versus email and spreadsheets guide helps define the shared workflow before choosing its implementation.
Bring the task worksheet and trial findings to a custom software conversation. A useful recommendation should explain which parts to buy, configure or build, and what evidence supports that decision.
Sources and calculation notes
The decision worksheet and illustrative weights are Anteomnio editorial guidance, not a validated scoring model. All financial inputs are hypothetical USD assumptions. Product scenario: $2,400 + 24 x ($300 + $150) = $13,200. Custom scenario: $12,000 + 24 x ($80 + $350) = $22,320. The comparison is not a supplier quote, market survey or claim that the two options meet identical requirements.
- GOV.UK Service Standard: Choose the right tools and technology. Total cost of ownership and preserving future technology choices. Applied here as a general decision principle, not a requirement for private businesses.
External references checked on 28 October 2026.