Build, Buy or Improve: Choosing the Right Technology Approach

The business situations in this article are fictional illustrations, not accounts of Parikh Advisory client engagements.

A distributor is comparing a custom platform with a subscription product. One quote is an upfront build; the other is a recurring fee. The operations director has a third option: fix the handoff and configure the software already in use. It receives the least attention because it looks less ambitious.

Illustrative scenario. The decision is not a contest between price tags. The company needs to know which capability matters, where the current process fails, how often it changes, and who will operate the result. Building, buying and improving the process should be compared against the same job.

Begin with the transaction that breaks

Follow one order from customer request to fulfilment. Perhaps sales enters it, warehouse staff adjust availability in a spreadsheet, and finance issues the invoice later. A custom system could connect these steps. A configurable platform might do so with less ownership. A clear rule for when stock is updated might solve the most damaging failure before either purchase.

Ask what would be different for the customer and staff if the problem were solved. Separate the core capability from the preferred implementation. Also identify what is genuinely distinctive to this distributor. A common invoicing task rarely justifies bespoke engineering by itself; a proprietary allocation rule or unusually complex integration might. The answer depends on the evidence, not the prestige of owning code.

Compare the whole commitment

A sensible comparison uses a time horizon and the same assumptions for all three options. Include initial setup, configuration or build, data migration, integrations, training, support, security, accessibility where relevant, recurring licences, maintenance, future changes and the time internal staff must contribute. Do not turn an uncertain five-year projection into a precise total. Show ranges and the assumptions most likely to change them.

• Improve: Change ownership, rules or handoffs within the current process. It can be fast and reversible, but may leave manual work and weak controls if volume grows.
• Buy: Configure an existing product. It can shorten the route to a supported capability, but the company inherits the vendor’s limits, pricing changes and integration model.
• Build: Own a tailored capability. It may support a genuinely distinctive workflow, but the company also owns maintenance, staffing, reliability and future adaptation.

Hybrid choices are common: use a standard platform for ordinary work and build only the narrow capability that differentiates the business. A decision record should say where the boundary sits and what would make it move.

Test the dependency people overlook

Suppose the subscription platform promises a live stock view. The warehouse still updates stock at the end of each day. The product may work exactly as sold while the customer promise remains unreliable. Before committing, test one real order with the vendor and the people who update the source data. Ask which data can be exported, who can correct an error, what happens when the integration fails, and how long the business can continue without the provider.

Vendor portability is more than a clause saying the company owns its data. Examine the export format, history, identifiers, attachments, configuration and the effort required to move to another tool. For a custom build, ask the equivalent question about source code, documentation, hosting, credentials and the availability of people able to maintain it.

Make a staged decision

The operations director can first agree the stock update owner and measure errors for a short period. In parallel, test a configured vendor journey with representative orders and exceptions. Commission a custom proof only if the distinctive workflow cannot be met acceptably and the organization is prepared to own the result. That is a sequence of decisions, not a presumption that every business must follow the same order.

The recommendation should name a decision owner and review trigger. If volume, exception cost or vendor constraints change, the preferred route may change too. Preserving that option has value, especially when current evidence is thin.

Questions worth putting in the comparison

• What customer or operating outcome must improve, and what is its current cost?
• Which parts of the workflow are common, and which truly differentiate us?
• What internal capacity will each option require after launch?
• Can we retrieve our data and change providers or maintainers without unreasonable disruption?
• Which assumption could reverse the recommendation, and how can we test it cheaply?

Research note: the UK Government Service Standard’s technology guidance calls for total cost of ownership and the ability to change choices later. Its commercial software guidance treats a purchased tool as part of an end-to-end service. These public-sector standards are useful decision prompts here, not rules that automatically apply to a private distributor.