Build, buy or integrate: when custom software makes sense

Custom software is not automatically the sophisticated choice. Sometimes it is an expensive way to reproduce a product that already exists. At other times, forcing an unusual operation through a generic tool creates years of manual workarounds.

The decision starts with the workflow that gives the business an advantage, not with a preference for code or subscriptions.

The three options are usually mixed

Buy means adopting an existing product and changing the process to fit it. Build means creating and maintaining software for a defined need. Integrate means connecting products so that information and work can move between them.

Most real systems combine all three. A business might buy a CRM, build a customer-pricing engine and integrate both with accounting. The U.S. government's 18F technology guidance makes the same practical point: projects often blend custom and commercial components, while heavy customization of commercial software can add risk. 18F De-risking Guide

Buy when the process is common

Start with an established product when the problem is shared by thousands of businesses: payroll, commodity accounting, email delivery, calendars and basic CRM are obvious examples.

Buying is attractive when:

• the workflow is not a competitive differentiator;
• regulatory and security maintenance would be costly to own;
• the product meets the requirement with configuration, not invasive customization;
• data can be exported in a usable form;
• the supplier's support and continuity are credible;
• the switching cost is understood.

The subscription price is not the total cost. Include implementation, migration, licences, training, integration, administration and the price of leaving.

Integrate when the tools are acceptable but the handoffs are not

Many "we need custom software" conversations are really integration problems. Staff retype a signed deal from the CRM into scheduling, then into invoicing. The products work. The seams do not.

Integration makes sense when each system has a clear role and reliable interface. Define which one owns each record, what event moves data, how duplicates are handled and what happens when an API call fails. A two-way sync without conflict rules can automate disorder.

Build when the workflow is both unusual and valuable

Custom software becomes a serious option when:

• the process creates a meaningful commercial advantage;
• available products force costly workarounds at material volume;
• the business owns enough stable knowledge to describe the rules;
• speed, permissions or user experience cannot be met by configuration;
• the organization can fund maintenance after launch;
• the value of a better process exceeds the full life-cycle cost.

A strong case might be a quoting engine built around proprietary risk logic, or an operations console that coordinates a workflow no common product models well.

A weak case is "we want everything in one dashboard" without identifying which decisions the dashboard improves.

Price the life cycle, not version one

Compare options over three to five years. Include:

• discovery and process design;
• implementation and data migration;
• hosting, licences and transaction fees;
• security updates and dependency upgrades;
• monitoring, backups and incident response;
• product changes when the business changes;
• vendor management and integration maintenance;
• exit, export and replacement costs.

18F's budgeting handbook recommends budgeting for product life-cycle costs and recurring services, not treating software as a one-time capital purchase. 18F Technology Budgeting

Run a reversible test

Before commissioning a platform, test the difficult assumption. A prototype might validate whether staff will use a new workflow. A manual concierge version might establish demand. A limited integration might show whether source data is clean enough.

The UK Government Service Manual describes discovery as the stage for understanding the problem, users and constraints before committing to build. It warns against beginning with a preconceived solution. GOV.UK Service Manual

Use a decision record

Write down:

1. the business outcome and current cost of the problem;
2. must-have requirements and what can change;
3. buy, integrate and build candidates;
4. life-cycle cost ranges and key assumptions;
5. security, privacy and continuity risks;
6. data ownership and exit path;
7. the smallest test that would change the decision.

Then revisit the record when facts change. A decision can be rational today and wrong two years from now because a product improved, volume grew or the workflow changed.

Custom software makes sense when it protects or amplifies something genuinely distinctive, and when the business is prepared to own a product rather than merely receive a project.

Source check

Government service-design guidance supports the discovery and life-cycle principles. It was written for public-sector delivery, so this article applies the principles to private businesses rather than claiming identical procurement conditions.

Sources

• 18F: De-risking custom technology projects
• 18F: Technology Budgeting Handbook
• GOV.UK Service Manual: How the discovery phase works
• Microsoft Cloud Adoption Framework: Define data ownership