An off-the-shelf system, or a platform to build your own

The question usually arrives as “off-the-shelf or custom”, and what it really means is “cheaper or more expensive”. That framing is wrong, because both options can be expensive and both can pay for themselves.

The real question is who adapts to whom. The company to the system, or the system to the company. Each carries a price; you simply pay it in a different currency and at a different moment.

The honest case for packaged software

Packaged software has three advantages no platform can imitate.

• A shorter start. You buy something that works from day one. There is no design phase, only a configuration phase.

• Proven industry processes. The vendor has served hundreds of similar companies and knows things about your industry that you do not yet. That is sometimes worth more than a tailored fit.

• Fewer decisions to make. An underrated benefit. Every design decision costs the time of somebody who has a company to run.

If your process is standard, packaged software is simply the better choice. Accounting, payroll, invoicing: there is nothing to invent here, and trying to build your own is a waste of money.

The honest case against packaged software

The price you pay for a package is invisible in the quotation and surfaces after a year.

The vendor's process gradually becomes the company's process. It starts innocently: the system has no field for what you need, so you put it in the notes. It does not support your approval path, so you simplify the path. Two years later the company works the way the vendor imagined, rather than the way its own decisions imply.

The second symptom is linguistic and more insidious. The system's vocabulary enters internal conversation. People stop talking about an order and start talking about a “type three document”, because that is what the screen calls it. That is the moment software stops describing the company and starts defining it.

The honest case for a platform

A platform reverses the dependency. The data model is yours: objects and fields are named the way you name them, not the way a vendor named them.

The second advantage is economic. A change is configuration rather than a chargeable order, so it costs less and, more importantly, needs no justification to anyone. The company fixes a process when it notices a problem, not when it has gathered enough arguments for a request to the vendor.

The third is tidiness: one system instead of five tools. A contract register, invoice workflow, complaints and internal requests can sit side by side and share the same data about counterparties.

The honest case against a platform

There is a bill here too, and it is better known before the start.

First, you have to know what you want. A platform will not suggest a process, because it does not know your industry. A company that cannot state who approves an invoice above a given amount will not solve that with any tool.

Second, somebody has to own it. Not a full-time role, but a specific name with the authority to decide, for a certain number of hours a month. Without that, a platform freezes in its go-live configuration and loses its entire advantage.

Third, it takes discipline. Freedom to configure without rules ends in configuration debt: three fields with similar names, a dictionary holding five variants of the same status, and a process nobody understands any more.

Three questions that settle it

Instead of comparing feature tables, answer three questions. The answers usually settle the matter in a quarter of an hour.

1. Is our process an advantage or an accident? If clients choose you partly for the way you work, do not hand that way of working to a software vendor. If the process looks like everyone else's because that is how it turned out, a package is fine.

2. How often does our offering change? A company launching new services and billing models every quarter will spend its life waiting on a vendor. A company with a stable offering will never notice.

3. Do we have somebody to own the system? If the answer is no and you do not intend to change that, choose a package or a ready-built instance. A platform without an owner is the worst of the available options.

The middle road nobody talks about

This choice is often presented as binary, and it need not be. There is a middle option: a ready-built instance sitting on a platform.

You get something that works from day one, with processes arranged for your industry, so the start is as short as with a package. The difference is that a platform sits underneath, so when a year later you need an extra stage or a new register, you do not change systems. You change the configuration.

That is how implementations for smaller companies are built in Opero, and it is usually the most sensible starting point: you neither ask the client to design a system from scratch nor lock them in a box.

In summary

Buy a packaged system when your process is nothing special and you have nobody to sit with the configuration. Choose a platform when the way you work is part of what clients pay for, and somebody inside the company will lead it.

The worst outcome is buying a platform while expecting a package, that is, expecting the system to work out how you should operate. It will not, and no system will.