Build, Buy or Integrate? A Fictional Service-Business Decision

For the business in this example, I would connect its existing tools before replacing them. That recommendation depends on two things: the tools must support a safe handoff, and someone must have time to maintain it. A cheaper estimate does not make either condition true.

This is an original fictional exercise. The business, tools, capabilities, workload and costs below were invented for this article. They are not an anonymized client project, vendor quotations, measured savings or completed implementation results.

Define the decision before choosing the software

Imagine a 14-person acoustic-survey studio called Bellweather. Its specialists visit offices, record sound measurements and prepare reports. Two coordinators manage approximately 100 completed jobs a month.

The job tracker already records when a survey is signed off. The billing tool already handles invoices. A coordinator copies job references and billing information between them, then checks a list to see what was missed.

The immediate need is narrow: make every signed-off job visible in a billing queue, with a draft invoice or an explicit exception for a person to resolve. An authorized person still approves each invoice. This project does not collect payments, replace the survey process or automate professional judgment.

“We need a new platform” would commit the business to an answer before it had defined the problem.

Make the constraints visible

These are planning assumptions for the fictional decision:

For the comparison, assume the current tools provide stable job identifiers, a way to read completed jobs, and a way to create and find draft invoices by an external job reference. Assume a candidate purchased suite also supports these requirements through its included connector. None of those capabilities has been tested; they are conditions of the exercise.

That distinction matters. A sales demonstration showing a successful invoice does not establish how duplicates, rejected records or uncertain responses behave.

Compare complete options

“Buy” still needs configuration, migration and an owner. “Integrate” still means operating software. The following estimates include technical setup, testing and handover, plus twelve months of technical maintenance after launch.

All dollar amounts are illustrative planning allowances. Engineering time is valued at an assumed $100 per hour, including internal time. Platform allowances are invented, not current market prices. Existing licenses and unchanged human invoice review are excluded because they are common to the options; any new operating burden discovered during validation must be added.

The calculation is the same for each row: (setup hours + 12 × monthly maintenance hours) × $100 + annual allowance. The integration row is (36 + 12 × 3) × 100 + 1,200 = 8,400.

The custom application fails three constraints before anyone debates its features: 150 setup hours exceed the available 48, six maintenance hours exceed four, and $23,400 exceeds $15,000. A weighted score should not let an attractive interface compensate for those failures.

Both buying and integrating remain eligible under the assumptions. Integration uses more setup and maintenance time than buying, but its illustrative first-year total is $3,200 lower. It also preserves a job tracker the team already uses and limits the change to the troublesome handoff. Those are the reasons to prefer it here, rather than a general belief that custom code is better than purchased software.

Record the choice and what could invalidate it

Decision record BBI-001: propose the integration pilot.

• Scope: turn signed-off jobs into a reviewable billing queue. Leave invoice approval and both systems of record in place.
• Owner: the fictional operations manager accepts the workflow; the engineer owns the adapter, its recovery procedure and technical maintenance.
• Reason: it meets the stated limits with less migration and a smaller change to daily work than replacing the tracker.
• Tradeoff accepted: the business owns a connection that can break when either tool changes. The lower allowance is not a support guarantee.
• Approval gate: validate the assumed integration capabilities and the complete handoff before committing the full budget.
• Revisit: a required capability is absent, the estimate exceeds a limit, the maintenance owner changes, or the existing tracker becomes the constraint.

The setup estimate leaves 12 hours inside the 48-hour delivery capacity. That is headroom, not proof the project will fit. Discovery could consume it. If validation changes the estimate, update the decision instead of quietly treating the deadline as flexible.

Test the handoff that the business will actually depend on

Before building the complete adapter, use invented records to test the following cases. These are proposed acceptance checks, not reported test results.

The queue needs a record of the source job ID, attempted action, known outcome and required next step. “Send every hour” is a schedule, not a recovery design. A failed notification also must not be confused with a failed invoice creation.

The fictional lending lab makes a related distinction visible: repeating a request and recovering from an uncertain notification are separate decisions. It is a small local model, not a billing integration or evidence that this proposed adapter works.

The pilot should also establish who notices exceptions, how they are resolved and whether the process fits ordinary working hours. An unattended error dashboard would leave the original business problem unsolved.

Change one constraint and reconsider

Doubling the job count alone would not establish that a custom system is necessary. It would create a capacity question to test. Likewise, removing the engineer would not make the purchased suite ownerless: the business still needs someone responsible for configuration, vendor changes and recovery.

Carry the reasoning into a real decision

Start with the outcome a person needs, write down the hard limits, and compare the work that each option leaves behind. Reject options that fail a required constraint before ranking the survivors. Then identify the smallest piece of evidence that could overturn the preferred choice.

The scenario and decision record are available as JSON, including the cost assumptions, arithmetic, acceptance cases and changed-constraint scenarios. It is an inspectable specification, not an executable estimator or a log from a completed experiment.

If you need someone to own that decision and help deliver the result, read about my fractional CTO work. For more technical explanations, browse the engineering notes.