Build, buy or rent: deciding capability by capability

“Should we build or buy?” is usually asked about the whole business at once, and at that level it has no answer. An enterprise is not one system. It is a set of capabilities: keeping accounts, paying people, buying material, running production, holding stock, dispatching, serving customers. Each can be decided separately, and each has a different right answer.

This guide gives a way to decide one capability at a time. It is fair to packaged software, which is the correct choice more often than its critics allow.

Three options, defined

The words are used loosely, so first a definition of each.

Rent. A subscription to a product that the vendor runs and every customer shares. You configure it. You do not change it.

Buy. A licensed package, often installed and customised for you. You hold a copy, and the vendor still decides what the product becomes. For the purpose of this guide, bought and rented sit on the same side of the line: someone else decides what the software does next.

Build and own. A system made for your operation, where you decide what is built and when, the knowledge of how it works stays with you, and the next system can be built on the same foundation. Note that a system built for you and then held by the vendor who built it does not meet this definition. It is rented with extra steps.

What to keep renting

Rent the capabilities that every business runs the same way. The clearest cases:

Statutory accounts and tax. The rules are set by law and are the same for you and your competitor. A product vendor tracks every change in them so that you do not have to.
Payroll. Again governed by rules that are not yours to design.
Email, documents and meetings. Nobody’s advantage lies here.
Standard HR records, expense claims and similar administration, unless the way you do one of them is genuinely unusual.

Three features mark a capability as one to rent. The rules come from outside the business. A competitor would be content to run it exactly as you do. And when the vendor changes the product, you are glad of the update and do not dread it.

For these, a packaged product is not a compromise. It is better than anything you would build, because the vendor spreads the cost of getting it right across every customer.

What to own

Own the capabilities that are how you compete, or how you actually run. They are usually found where the physical operation is: the gate, the floor, the warehouse, the desk where orders are promised.

The marks of a capability to own are the reverse of the list above.

It uses your own vocabulary. The trade has words for its units and steps that no general product contains. A cloth finishing unit counts lumps, metres and bales, weighs its lowest grades in place of measuring them, and sometimes opens a packed bale to repack it for another buyer. A general stock module offers “item” and “quantity”.
The exceptions are daily. A short delivery, a load that fails a quality check, goods that go straight from vendor to customer. If these are routine, the software has to treat them as ordinary paths.
It changes when the business changes. A new customer, a new site, a new rule from management. If the process moves several times a year, you need to be able to move the system with it.
Money, stock or a promise depends on it. This is where a wrong record costs something.

A simple way to see the difference: accounts record the result of the operation, and the result is the same kind of thing in every company. The operation that produces it is not.

The questions that sort one from the other

Take each capability and ask these seven questions. Write the answers down. The pattern is usually obvious by the fourth.

Would a competitor run this in exactly the same way? If yes, lean towards renting.
Who sets the rules: a regulator, or us? Outside rules favour a product. Rules you set favour ownership.
How often has the process changed in the last two years? Rarely: rent. Often: own.
Is there a spreadsheet, a register or a group chat running beside the current system? If people have built their own tools around it, the product has already stopped short.
When this goes wrong, what does it cost? A capability where an error means lost stock or a broken promise deserves more control than one where it means a late expense claim.
Do our people use words for this that the software does not? Count them. More than a handful suggests the model is not yours.
If we wanted to change it next month, who would we have to ask? If the honest answer is a vendor’s product team, and the capability matters, that dependence is the cost.

A worked example

Consider a mid-sized manufacturer with a spares and consumables unit. Go through its capabilities one at a time.

Capability	What the questions show	Decision
Accounts and tax	Same as any competitor. Rules set by law. Nothing runs beside the system.	Rent
Payroll	Same as any competitor. Rules set by law.	Rent
Email and documents	Same everywhere. No rules to speak of.	Rent
Spares orders, from request to dispatch	Particular to the business, which sets the rules. Several sheets and a chat group run beside the system.	Own
Stock on the floor, in the trade’s own units	Particular to the business. Kept in handwritten registers.	Own
Management reporting on the two above	Rebuilt by hand each month from the sheets.	Own, with the system it reads from

The table is not exotic. The spares and consumables unit of an engineering group looked much like the fourth row of that table before its present system: requests arrived by email, message, spreadsheet, PDF and handwritten slip, quotations lived in their own files, and receipts and dispatch sat in one shared register kept by one person. The accounts were never the problem. They stayed in the accounting package, and the system the group runs for spares today covers the order from request to dispatch.

Most enterprises that do this exercise honestly end up with a short list to own and a longer list to keep renting. That is the right shape. The aim is not to own as much as possible. It is to own the right few.

The usual mistakes when renting

Bending the operation to fit the product. A little of this is healthy: some habits are only habits. It becomes a mistake when the thing bent is how you serve a customer or control a cost.

Customising a package until it is no longer a package. Heavy customisation gives you the cost of a build with the constraints of a product. Each vendor upgrade then becomes a small project.

Calling a workaround a solution. If the packaged system is “live” and the real work happens in a sheet beside it, the capability is running without a record: no history, no permissions, nothing that reconciles.

Renting something that changes monthly. Every change becomes a request, an estimate and a wait. The process ends up changing only as fast as someone else’s queue.

The usual mistakes when building

Building what a product does well. An in-house payroll or accounting system is almost never justified. If the seven questions say rent, rent.

Starting with the foundations. Logins, permissions, approval routing and reporting are the same everywhere. A build that spends its first months on them is rebuilding plumbing. Start from a base that already has them.

Building from the process document. The document describes the normal case. The operation lives in the exceptions, and those are found by standing at the gate or the packing table. A system specified from a meeting room is correct on paper and loses to the spreadsheet in use.

Building without ending up as the owner. If only the vendor’s team understands the result, you have paid to build and are still renting. Ask what will be written down, and what you could do with it if that team left. Another article here covers what a first build should leave behind.

Building everything at once. One capability, end to end, live and in use, teaches more than a programme plan for ten.

A checklist for Monday

List your capabilities in plain words, one line each.
Against each, note the system it runs in today and any sheet, register or chat that runs beside it.
Ask the seven questions of each line.
Mark each one rent, own or leave alone. “Leave alone” is a valid answer for anything small and infrequent.
From the lines marked own, pick the one where an error costs most. That is the first candidate.
For that one, write down its exceptions before its rules.

The list itself is worth having even if nothing is built. It is a map of where the enterprise depends on someone else, drawn by capability.

Where the cost of owning stands now

For a long time the “own” column was mostly theoretical. Building an operational system took a year and a large team, so even capabilities that clearly belonged inside stayed in spreadsheets.

That cost is what has moved. Phlo, the framework Jetbro builds on, already contains the foundations, and AI compresses the development timeline while people spend their time understanding the operation. Jetbro builds the first system with you. After that the framework becomes available to you, so your own engineers can build the next one on it, or Jetbro can carry on. The capabilities on your rent list stay exactly where they are.