Choosing between a platform and a custom build

Every business considering new software eventually arrives at the same fork. A product exists that covers most of what is needed. It does not cover all of it. Do you adopt the product and change how you work, or build something that fits how you already work?

Framed that way the question has no good answer, because both options are being compared as wholes. The decision becomes tractable when you separate the system into parts and ask the question about each one.

The test

For any given process, ask: if a competitor did this exactly the way we do, would we lose anything?

For most processes the honest answer is no. Your payroll calculation is not a competitive advantage. Nor is your general ledger, your stock valuation method, your leave approval flow or the way you record a purchase order. These are solved problems where the accumulated design of a mature product is almost certainly better than what you would specify from scratch — and where insisting on your own version means paying to rebuild something standard and then paying again to maintain it.

For a small number of processes the answer is yes, and those are usually the ones currently held together by spreadsheets, WhatsApp groups and one person who understands the whole thing. The way you price a complex freight job. The rules deciding which vehicle takes which load. The approval chain that keeps your particular risk under control. That is where your margin comes from, and it is worth building properly.

The pattern that usually wins

Buy or configure the standard parts. Build the distinctive parts. Integrate them properly. Most businesses that report a good outcome from a software project did some version of this, and most that report a bad one committed wholly to one side of the fork.

When a product is the right answer

• The process is standard, and your version of it is different mostly through history rather than design.

• The domain has regulatory complexity you would rather not own — tax computation, statutory payroll, compliance reporting.

• You need it working in weeks rather than months.

• The team that will maintain it is small, and a well-supported product is a lower ongoing burden than bespoke code.

When building is the right answer

• The process is genuinely yours, and adopting a standard version would remove something that makes you money.

• The integration between systems is the actual product — the value is in the connection, not in either endpoint.

• You have tried products and each requires enough configuration and workaround that you are effectively building anyway, at higher cost and with less control.

• The requirement is narrow and specific. Small bespoke tools are often much cheaper than the licence for a large product used at ten per cent of its capability.

Two questions worth asking before either

Who maintains this in three years?

Bespoke software is an asset with an ongoing cost. If the answer is one developer who also does everything else, that is a risk to weigh — not a reason not to build, but a reason to insist on documentation, tests and a handover as part of the delivery rather than a hope for later.

What happens when we outgrow this?

A product has a ceiling defined by its vendor. Bespoke has a ceiling defined by its architecture. Both exist. The question is whether you will reach yours in three years or thirty, and whether the exit — migrating off, extending, replacing a component — has been thought about at all.

The most common mistake

Building the standard parts because they were easy to specify, and buying the distinctive part because no product quite fit and configuring one felt like progress.

This is a natural outcome of scoping software by writing down requirements: the standard processes are easy to describe, so they get described first and in most detail, while the distinctive process is the hardest to articulate and gets deferred. The result is a system that reproduces commodity functionality at custom cost and compromises the one workflow that actually differentiates the business.

Scope by asking what is distinctive first. The rest follows more easily than you expect.

Questions or a correction? Contact the 2M team. Examples explain a method; results depend on your operation and configuration.