Build vs Buy Internal Software: Buy, Configure or Build?

Buy an existing product when it supports the essential work without burdensome workarounds. Configure and connect it when a specific, manageable gap remains. Build a custom internal tool when an important requirement still cannot be met sensibly, and the business can support the software after launch.

The build vs buy internal software decision should start with one actual job: how someone requests work, who assigns it, who approves it and how staff record completion. Test a correction too. A product can look convincing until somebody needs to reopen a completed job.

I would test the most frequent handover before comparing feature lists. A missing report used occasionally may be tolerable; re-entering every completed job into another system may determine whether buying is economical.

Start with one job, including the awkward part

Choose a representative job and follow it from request to completion. Use actual, suitably anonymised records so that awkward details survive the test: incomplete instructions, reassignment, rejected approvals and corrected completion notes.

Separate essential outcomes from familiar habits. An essential requirement might be that staff cannot approve their own work. A preference might be that the approval screen resembles the existing spreadsheet.

This distinction also appears in Maryland's build-versus-buy guidance, which cautions against choosing custom development simply because a business is reluctant to consider alternative processes. An awkward process is not, by itself, a reason to reproduce it in software.

A worked example: managing maintenance jobs

Illustrative scenario: a maintenance business receives requests, assigns technicians and requires a supervisor to approve completed work before the office prepares an invoice. Technicians should see their assigned jobs, but only supervisors can approve them. Occasionally, a supervisor returns a job for correction.

For this example, assume the essential requirements are:

• The request, assignment, completion notes and approval stay attached to the same job.
• A technician cannot approve their own work.
• Approved completion details reach the invoicing system without routine retyping.
• A correction updates the existing job rather than creating a second billable record.
• The business can export job records, approval history and attachments in usable formats.

A particular screen layout is negotiable. The approval restriction and protection against duplicate billing are not. All three options should be tested against these same requirements.

Compare three approaches to the same work

Buy an existing product when the standard workflow fits

In the maintenance example, staff enter a request, assign a technician and approve completion using the product's existing workflow. Buying is sensible if staff can perform these tasks, handle corrections and pass the necessary details to invoicing without an unreasonable manual burden.

Be willing to change harmless habits. If the product calls an approved job “closed” rather than “complete”, that need not justify custom development. But a product that cannot separate completion from supervisor approval fails an essential requirement in this example.

The supplier maintains the core product. Your business still owns user administration, workflow settings, training and checking that releases have not disrupted important work.

Configure and integrate when the gap is narrow

Suppose a product handles requests, permissions and approvals well, but the office still copies every approved job into the invoicing system. Before rejecting it, test whether configuration or a supported connection can remove that step.

The connection must do more than transfer a successful example. Establish which system holds the definitive job record, how the same job is recognised in both places, what happens after a correction and who deals with a failed transfer. Retrying a transfer must not create another invoice.

Confirm the required capabilities against current product documentation and the proposed subscription plan. Ask for a demonstration of permissions, exports and update behaviour rather than accepting “integrates with your accounting software” as sufficient detail.

This option works well when the product remains a good home for the main process and the connection has a clear boundary. It becomes less attractive when every step needs another workaround, script or external screen. Someone must maintain the configuration and connection as either system changes.

Build when an essential gap survives those tests

A custom internal tool becomes a credible choice when the required workflow cannot be accommodated without substantial recurring compromise. In the example, that might mean available products cannot enforce the required approval restrictions or preserve the necessary correction history, even after configuration has been explored.

A build lets the team design those behaviours explicitly. It also makes the business responsible for commissioning, testing and maintaining them. Compare a written, testable build scope with the product trial, not an imagined system that does everything perfectly.

Custom software does not automatically mean easy exports, strong security or independence from a supplier. Those need to be specified in the design, contract and support arrangements. Identify who will handle access changes, backups, security updates, faults and future changes before approving development.

Use this brief for a fair workflow trial

Give product suppliers, implementation partners and potential developers the same brief. For a proposed custom build, use it to assess the design and acceptance criteria, then require a working demonstration before accepting the relevant work.

• Job and volume: describe the request-to-completion path, how often it occurs and who performs each step.
• Essential outcomes: state what must happen, why it matters and what would count as failure. Keep preferences separate.
• Test records: provide anonymised examples of a normal job, a common exception and a completed job that needs correction.
• Access: specify what each staff role can view, change, approve and export.
• Handover: identify the information that must reach another person or system, including later corrections.
• Recovery: ask what happens when approval is rejected, a transfer fails or somebody submits the same action twice.
• Exit: require a sample export and check whether records, attachments and history remain understandable outside the system.
• Ownership: name the business owner and the person or supplier responsible for configuration, connections and technical support.

Have the staff who actually perform the work take part. A demonstration by an experienced salesperson can conceal steps that your team will struggle to repeat.

Record the work left behind, not a feature score

For each option, complete the following comparison worksheet. Use observed trial results where possible and mark anything that still needs proving.

• Essential requirement: passed, failed or unproven, with the evidence.
• Manual work remaining: what staff must copy, check, reconcile or chase.
• Frequency: whether that work occurs on every job, regularly or only in an unusual case.
• Consequence: delay, missing information, unauthorised approval, duplicate billing or a minor inconvenience.
• Proposed remedy: process change, configuration, integration or custom development, including who maintains it.
• Rollout and exit: training, migration, support and export work still required.

A rare exception may justify a documented manual procedure. A routine handover that needs copying and checking deserves much closer attention. Neither conclusion follows from the percentage of features covered.

Compare the operating commitment, then decide

Use the same planning period and expected staff numbers for every option. Include setup, migration, training and ongoing operation, rather than comparing a subscription price with a development quote.

For a purchased product, include the required subscription tier, user growth, administration and remaining manual work. For a configured product, add connection charges, monitoring and maintenance. For a custom tool, include development, hosting, support, security updates, backups and future changes. All options may involve eventual migration costs.

Estimate recurring workaround effort from the trial: time per occurrence multiplied by expected frequency. Keep routine re-entry separate from occasional corrections, and use your own staffing assumptions. This makes the burden visible without pretending it is a guaranteed cash saving.

Then apply these decision rules:

• Buy if essential requirements pass and the remaining compromises are acceptable to the people doing the work.
• Configure and connect if a demonstrated, supportable change closes a specific gap without creating a fragile chain of workarounds.
• Build if a consequential requirement remains unmet, the proposed scope addresses it directly and ongoing ownership is funded.

If a decisive requirement remains unproven, commission a focused test before committing to the full implementation. In the maintenance example, demonstrate the approved-job transfer and subsequent correction first. If that works reliably in an otherwise suitable product, a custom internal tool may be unnecessary.