Buy, configure, or build: how to decide

The three options are not degrees of the same decision

They are usually presented as a scale of customization: buying is the fast option, building is the bespoke one, and configuring sits in between. That reading is wrong, and it explains a good share of the projects that stall.

They are three different commitments. When you buy, you adopt the business model built into the product and adapt your operation to it. When you configure, you adapt a platform to your process within the limits the platform allows. When you build, you define everything — and you keep the maintenance forever.

When should you buy?

When the problem is already solved and is not where you compete. Accounting, payroll, invoicing, document management, ERP: thousands of organizations have walked that path and the product carries their lessons.

The most useful warning sign here is an uncomfortable one: if your process does not fit the product and you cannot explain in one sentence what commercial advantage that difference buys you, the process is what is wrong, not the product. Customizing an ERP to preserve a way of working nobody consciously chose is the most common way to turn a purchase into a development project.

When should you configure?

When the problem is common but your operation is not. This covers most projects, and it is the option most often underestimated.

Serving customers over WhatsApp is a common problem: mature platforms resolve connectivity, deliverability, the inbox, routing, and analytics. But how you qualify a prospect, when a person steps in, and what happens to a conversation that did not close is specific to each organization. Configuration is not a limitation there: it is where it is decided whether the system is any use.

Today's platforms allow far more adaptation than they are given credit for. Before concluding that you have to build, it is worth knowing exactly where the one you already have runs out.

When should you build?

Only when the problem is yours and is what sets you apart. Not when the platform feels awkward, not when a feature is missing, and not when the vendor is slow to reply.

We built WePadel, our own product for padel communities, for that reason: a player's history and ranking had to survive changing club, and no existing platform allowed it because they all assume the data belongs to the club. It was not a missing feature, it was the premise of the product. That is the threshold.

If what you are missing can be written as a list of features, you are not at that threshold yet.

The cost almost nobody calculates

Building does not end at go-live. It starts there. What you buy by building is not a system: it is the permanent obligation to maintain, update, fix, and evolve it for as long as the business exists.

That commitment is reasonable when the system is your differentiator. It is hard to justify when all you wanted was to sidestep a platform limitation that was going to be fixed two releases later.

Four questions to decide

Before choosing a path, answer these four. If you hesitate on any of them, you do not yet have the information to decide.

• Is this process where you compete, or just something that has to work?
• If your operation does not fit the product, can you explain in one sentence what that difference gains you?
• Have you checked where the platform you already use actually runs out, or are you assuming it?
• Who maintains what you build three years from now, and on whose budget?