Strategy
When to buy the package instead
The most useful thing a custom software firm can tell you is often that you should not commission any. Here is the test, and what is actually left to build once you have bought well.
In short
- Packaged and vertical software is usually the correct purchase, and a firm that tells you otherwise as a rule is describing its own business model rather than your problem.
- The test is not feature coverage. It is whether the workflow the package cannot model is the one your margin actually comes from, if it is commodity, buy and adapt; if it is the differentiator, that specific part is what deserves to be built.
- In-package customization is where budgets go quietly. Bending a package far from its defaults is expensive, slow and fragile, and it is charged again at every upgrade.
- Integrations are almost never as standard as the demo implies. The connector list is a list of products, not of your instance of them, and this is where most of the real work turns out to be.
- The durable pattern is a perimeter: buy the system of record, own the integration layer and the one differentiating workflow around it, and never propose replacing the package you just recommended.
We are a custom software firm, so treat what follows with the appropriate suspicion and then check it against your own situation. Most organizations that ask us to build something would be better served buying something, and we would rather say that in the first conversation than discover it together in month four.
Packaged software in a vertical (a TMS in freight, an EHR in health, a Tyler-class system in local government, an MES on a plant floor) represents decades of accumulated domain knowledge that nobody is going to reproduce on a project budget. It is usually cheaper, usually faster, and frequently just correct. A firm whose answer to every problem is a custom build is describing its own business model rather than your problem.
That is not the same as saying you should buy and stop. The question worth getting right is which parts of your operation belong inside a package and which do not, because getting that boundary wrong is expensive in both directions.
The test is not the feature matrix¶
Procurement usually runs on coverage: which product ticks the most requirements. That produces a ranking and hides the decision, because it treats all the unticked boxes as equivalent when they are not.
The better question is about the gap rather than the coverage. Take the workflow the package cannot model and ask what it is. If it is administrative (a report in a particular shape, an approval order somebody is attached to) buy the package and change the workflow. If it is the thing your customers actually choose you for, the thing your margin comes from, then you have found the part that deserves to be built, and it is usually much smaller than the system around it.
Two costs that are systematically underestimated¶
When a package purchase goes badly, it is rarely because the product was bad. It is almost always one of these two, and both are visible before signing if you look for them.
| Where it goes wrong | Why it is underestimated | What to ask before signing |
|---|---|---|
| In-package customization | Bending a package away from its defaults is priced as configuration and behaves like development, slower, more fragile, and re-tested or re-done at every upgrade, because it lives inside somebody else's release cycle. | Which of our requirements are met by configuration, which by customization, and what happens to each at the next major version? |
| Integrations | The connector list is a list of products, not of your instance of them. Two organizations running the same ERP and the same package can need entirely different work to connect them, and in some sectors the integrations are never standard at all. | Has this vendor connected to our exact systems, at a customer we can speak to, and what was actually built to do it? |
Neither of these is an argument against buying. They are an argument for pricing the purchase honestly, which usually still leaves it the better decision, and occasionally reveals that the quote you are comparing against a build was never the whole number.
Buy the system of record; own the perimeter¶
The pattern that holds up over years is not custom-versus-packaged. It is a package doing what packages are good at (being the system of record, carrying the compliance surface, absorbing regulatory change on somebody else's roadmap) with a thin, well-defined layer around it that belongs to you.
That layer is generally three things: the integration surface between the package and everything it does not know about, the one workflow that is genuinely yours, and the reporting that answers questions the package was never designed to be asked. It is a fraction of the size of the system it surrounds, and it is the part where being different from your competitors is worth anything.
The discipline that makes this work is refusing to propose replacing the package afterwards. A perimeter that grows until it has quietly reimplemented the system of record is the failure mode of this approach, and it is a failure we would own rather than the vendor.
What we do about this in practice¶
If a paid discovery with us ends in the conclusion that you should buy something, you get that conclusion in writing, with a named shortlist and the reasoning, and you keep it whether or not we do any further work. It is a cheap thing for us to do because the discovery is already paid for, and it is the only version of this advice that is worth anything; an opinion that costs the person giving it nothing is not evidence of much.
Where it goes the other way, the scope we propose is the perimeter and not the package. That is a smaller engagement than most people expect to be quoted, and it is the one we can defend three years later.
Related reading
- Strategy4 min read
Build versus buy: the only test that actually settles it
Most build-or-buy debates are decided by whoever presents last. There is a better question, and it takes about ten minutes to answer.
- Strategy5 min read
When a spreadsheet becomes a system
Most operations run on a spreadsheet, and most of them should carry on doing it. But there is a real line, it is not where people expect, and crossing it is not obvious from the inside.
Next step
Tell us what’s breaking.
Forty-five minutes, no charge, no deck. We’ll tell you what we’d do, what it would likely cost, and whether what you already have can be made to work.