A build-versus-buy decision that includes the next three years

The initial quote is usually the easiest part of a build-versus-buy comparison. The difficult parts arrive later: a supplier changes its interface, the original developer leaves or the organisation needs an export the product was never designed to produce.

I would compare the options over an operating horizon long enough to expose those obligations. Three years is a useful planning window for many internal tools, provided it is treated as a scenario rather than a promise about future prices or demand.

Compare the same service boundary

A custom-build estimate may cover development while a subscription includes hosting and support. A software quote may omit integration and training while an internal estimate includes them. Comparing the headline totals creates false precision unless the boundaries match.

Describe the required service first. Include the ordinary task, material exceptions, identity needs, data flows and expected support hours. Then ask what each option supplies and what the organisation must still provide.

For a fictional equipment inspection register, an off-the-shelf product might handle scheduling and reminders but require a separate reporting connector. A custom tool might fit the inspection process closely but need someone to maintain authentication, exports and operating procedures. The comparison should include those differences explicitly.

Keep a third option available: change the process or use a capability already owned. A binary build-versus-buy discussion can overlook a smaller intervention that solves enough of the problem with less ongoing work.

Price the ordinary years after launch

List the recurring obligations before assigning costs. For a build, these may include dependency updates, incident response, hosting, security review and changes to business rules. For a purchase, they may include licences, support tiers, administration and integration maintenance.

Internal effort is not free because the people are already employed. It competes with other work. Show the capacity required and the work it would displace. Equally, avoid treating every theoretical hour saved as a cash saving unless the organisation has a credible way to realise it.

Use explicit scenarios for uncertain inputs. A low-demand case, expected-demand case and higher-demand case can reveal whether per-user or usage-based pricing changes the preference. Label all illustrative costs as hypothetical and distinguish them from supplier quotes. There is no benefit in decorating an uncertain model with unnecessary decimal places.

Check what triggers a different price or service tier. External users, storage, API access and test environments may be priced differently. Ask about renewal terms and the effect of reducing usage as well as increasing it. The cheapest first year may be a poor fit if the service becomes expensive to change or leave.

Test ownership under uncomfortable conditions

For a custom build, ask whether another competent team could maintain it. Review the code, deployment process, documentation and rights to use the work. A repository alone is not a support model. Someone needs access, context and time to respond when the tool fails.

For a purchased service, examine the responsibilities that remain internal. The supplier may run the platform while the organisation still owns access decisions, data quality and process configuration. A contract cannot perform those tasks on its own.

I would test each option against a few scenarios: the main technical contact is unavailable; a critical integration changes; a new reporting requirement appears; or the organisation needs to leave. Describe the work and authority required to handle each event.

This is also where managed-service accountability matters. Paying another party to operate components can be sensible, but the organisation still needs someone able to understand the boundary and make decisions about it.

Inspect the exit before signing

Ask for a representative export and examine it. Can records, attachments, identifiers and relationships be reconstructed elsewhere? Does the export include the history the business needs, or only the current screen values? An export button is not enough evidence by itself.

Review the assistance required to migrate, the relevant contractual terms and any costs that are not included. Consider how long the organisation would need parallel operation and who would reconcile changes during it. These questions apply to custom tools too, especially when they depend heavily on a particular platform.

Open formats and documented interfaces can reduce some switching costs, but they do not remove all lock-in. Business rules, staff familiarity and integration design also create dependencies. State which of those dependencies the organisation is willing to accept.

Where an exit is expensive but the service remains the best choice, record the reason. The aim is an informed trade-off, not a claim that every dependency can be eliminated.

Make a conditional recommendation

A useful decision paper explains why an option suits the organisation's current capability and constraints. It should identify the assumptions that would justify revisiting the choice. A custom tool may be reasonable for a distinctive process with funded maintenance. A product may be preferable for a common process where standardisation is acceptable.

Name the operating owner and secure the ongoing budget before treating the decision as complete. If neither option has a credible owner, the organisation has not finished deciding how it will deliver the service.

The final comparison should be readable by the people who will live with it. They need to understand the service they are acquiring, the work they are retaining and what could make today's sensible choice unsuitable later.