When Should You Build a Custom Business App Instead of Buying Software?

Choose between buy, integrate and build

A build-versus-buy decision is rarely binary. There are normally three options: adopt and configure a product, connect or extend existing systems, or create a focused application. Treating integration as a separate option matters because many businesses already own most of the capability they need; the failure sits in the gap between systems, teams or decisions.

Write one sentence for each option. State what would change for the user, which systems remain authoritative, who would own the service and what risk remains. If the team cannot explain an option without naming dozens of features, the problem is not yet clear enough for a fair comparison.

• Buy and configure when the process is standard and vendor-supported behaviour is acceptable.
• Integrate or extend when existing systems cover the core work but data and decisions do not move safely between them.
• Build when the workflow is specific, valuable and stable enough to justify an owned service.

Start with the user problem and a measurable outcome

Begin with the people doing or receiving the work. Observe where they wait, re-key data, chase approval, correct mistakes or lose evidence. GOV.UK's Service Standard starts with understanding users and the problem in its full context, then asks teams to define what success looks like and publish performance data. The principle applies equally to a commercial back-office tool.

Turn the observation into an outcome that can be tested. Instead of “we need an app for quotes”, use “a sales adviser can assemble a technically valid quote, obtain the required margin approval and show the evidence without copying product data between three spreadsheets”. Add a baseline such as elapsed time, rework rate, exception backlog or number of manual hand-offs.

A feature request describes a proposed answer. A user outcome describes the result that every option must prove. Keeping those separate prevents a familiar product demo or attractive prototype from deciding the project before the real need has been tested.

Check whether the process is stable enough to automate

Software makes a process repeatable; it does not make an unresolved policy coherent. If two managers use conflicting approval rules, product identity changes between files, or nobody knows which record is authoritative, coding the current behaviour can make the disagreement faster and harder to see.

Map the trigger, users, inputs, decisions, exceptions and completed outcome. Run several real cases through the map, including awkward ones. Mark where a person uses judgement and where a rule is genuinely repeatable. If the process changes every week because the business is still learning, use a lightweight trial and improve the process before committing to a durable build.

• The trigger and completed outcome are unambiguous.
• The people responsible for each decision are named.
• Important data has a known source and stable identifier.
• Common exceptions can be recognised and routed safely.
• The team agrees what must be logged, reviewed or approved.

Test off-the-shelf fit with real work, not a feature list

A long feature list can hide a poor operational fit. Create a small set of representative scenarios and ask each supplier to demonstrate them using realistic roles, records and exceptions. Include a routine case, a permission-sensitive case, a correction, an integration failure and an exit or data-export case.

Score the result against must-have outcomes rather than the number of available settings. Check identity, data ownership, permissions, audit evidence, accessibility, reporting, integration boundaries, recovery and support. A missing convenience feature may be tolerable; a workaround that breaks product identity or bypasses approval is not.

Also test the cost of adapting the business. Changing a harmless preference to match a supported workflow can be sensible. Forcing a safety, compliance or customer promise into a generic model may move cost from the software budget into errors, supervision and manual reconciliation.

Buy when the capability is common and support matters most

Buying is usually the stronger choice when many organisations perform the same job in a similar way, the vendor product meets the critical scenarios, and regular updates, documentation and support are more valuable than unique behaviour. Payroll, commodity ticketing and basic document collaboration often fit this pattern, although the exact assessment still depends on the business.

Confirm the operating model before signing. Identify configuration limits, data portability, authentication, permissions, service levels, update policy, pricing drivers, migration effort and the route out. The Technology Code of Practice recommends defining user needs, choosing purchasing strategies deliberately, using open standards where possible and considering the full technology lifecycle.

Integrate or extend when the core systems already work

A business may already have an ERP that owns stock and pricing, a CRM that owns opportunities and an ecommerce platform that owns checkout. Replacing any one of them to fix a broken hand-off may create more risk than it removes. A governed integration or a small workflow layer can preserve the systems of record while improving the journey between them.

This option still needs explicit boundaries. Define the authoritative identifier and owner for every important field, the direction of each update, how duplicate or late events are handled, which failures stop processing and how a person resolves an exception. A thin user interface over vague ownership is not an integration strategy.

Build when the workflow creates distinctive value

A custom application becomes credible when the workflow materially affects revenue, cost, risk or customer experience; repeats often enough to justify change; and cannot be supported well without damaging workarounds. Specific data relationships, permissions, evidence requirements or decision paths may make a generic product a poor fit.

Custom does not mean replacing every platform. The most useful application may be a focused service that connects approved systems and governs one important outcome. M.I.A.I Builder is designed to turn a plain-English application request and focused clarification into a governed, reviewable application path, with verification and controlled delivery built into the approach.

The final condition is ownership. A named person or team must own priorities, access, data quality, support, change decisions and retirement. If nobody will operate the service after launch, the organisation has not chosen to build; it has chosen to accumulate an unmanaged dependency.

Compare total lifecycle cost, not licence price against build price

A fair comparison covers the same time horizon and the same outcome. For a purchased product, include discovery, licences, configuration, implementation partners, migration, integration, training, support, vendor price changes and exit. For a custom application, include discovery, design, development, testing, hosting, monitoring, security work, support, enhancement, documentation and eventual decommissioning.

Record costs that are easy to hide: repeated manual reconciliation, duplicate entry, approval delays, failed imports, supervision and the opportunity cost of people working around the software. Do not convert every benefit into a confident financial number. Keep assumptions visible, use a range where evidence is uncertain and update the case after the pilot.

• Acquisition and initial implementation
• Data migration and integration
• Training, adoption and process change
• Security, privacy, accessibility and assurance
• Hosting, monitoring, support and incident recovery
• Upgrades, requested changes and supplier price movement
• Data export, transition and retirement

Make security, privacy and accessibility entry conditions

These are not extras to add after the option has been selected. Identify sensitive data, retention, access roles, authentication, audit needs, recovery expectations and accessibility requirements during evaluation. A product that cannot meet a non-negotiable control is not the cheapest option, regardless of its headline price.

NIST's Secure Software Development Framework recommends integrating security practices throughout the software development lifecycle rather than treating them as a final inspection. Purchased software also needs due diligence: understand how the supplier develops and updates it, what evidence is available, how vulnerabilities are handled and which responsibilities remain with your organisation.

Use the minimum access needed, separate approval from execution where the risk warrants it, and make significant actions traceable. For custom work, include these conditions in acceptance tests. For bought software, include them in the evaluation, contract and ongoing review.

Decide who will own and operate the service

Name a service owner before approving the solution. That person does not need to write code, but must be able to prioritise outcomes, accept or reject changes, coordinate incident decisions and confirm when the service is still worth operating. Product ownership cannot end when implementation ends.

Define the support route, service hours, monitoring, backup and recovery, supplier escalation, access reviews, release approval and documentation. Agree how urgent fixes differ from planned improvements. These operating commitments often reveal that a promising prototype is not ready to become a business-critical service.

A concrete example: a governed quote approval workflow

Consider a technical distributor whose sales team prepares quotes for replacement components. An adviser must identify the customer's machine and serial range, select a compatible product, check current price and availability, apply an approved margin rule, obtain manager approval for exceptions and retain the evidence used. Today the work crosses an ERP, CRM, product files, email and spreadsheets.

Buying a new CRM does not solve the product and approval logic, and replacing the ERP would put stock and pricing at unnecessary risk. A generic workflow product can move tasks but cannot prove the required product relationship without extensive workarounds. The decision team therefore keeps the ERP and CRM, then evaluates a focused application that reads approved records, guides the adviser through the decision and writes back the quote status without changing the authoritative product or stock records.

The first release covers one product family, one sales team and two approval outcomes. It carries stable source identifiers, records the rule version and evidence, blocks an unconfirmed compatibility claim, and sends exceptions to a named reviewer. The pilot measures elapsed quote time, rework, exception age and corrections after approval. That evidence determines whether to extend, revise or stop.

Run the smallest end-to-end pilot that can disprove the idea

A useful pilot is not a collection of attractive screens. It takes a real case from trigger to governed outcome with actual roles, representative data, an exception and a recovery path. Its purpose is to expose weak assumptions before the organisation scales them.

Choose a narrow user group and a bounded transaction type. Define the baseline and pass conditions in advance. Include usability, data accuracy, permissions, accessibility, operational support and failure handling. If the pilot misses the outcome, investigate why instead of adding features automatically.

M.I.A.I Builder begins with a simple prompt, asks focused questions that affect the outcome and keeps creation governed and reviewable. That can help a business move from a broad idea to a testable application path, but the business must still provide the process knowledge, owners, data decisions and evidence of success.

1. Write the user outcome, baseline and non-negotiable controls.
2. Select representative cases, including at least one exception.
3. Build or configure the smallest complete workflow.
4. Test with the people who do the real work and support it.
5. Compare results with the baseline and record unresolved risks.
6. Choose to adopt, change direction or stop.

Use a decision record instead of a one-off score

A weighted score can help teams compare options, but the final number can conceal a failed requirement. Keep a short decision record that lists user evidence, must-have outcomes, tested scenarios, assumptions, costs, risks, rejected options, owner and review date. Mark non-negotiable conditions separately from preferences.

Revisit the decision when transaction volume, regulations, supplier terms, core systems or user needs change. Buying today does not prevent building later; a focused custom workflow does not justify replacing the platforms around it. The goal is not to defend the original choice forever, but to keep the service useful, safe and economically sensible.

• What user problem and measurable outcome are we addressing?
• Which option passed every non-negotiable scenario?
• Which data, permissions and systems does it depend on?
• What does the lifecycle cost range include and exclude?
• Who owns operation, support, change and retirement?
• What evidence would make us review or reverse the decision?