When to buy the package instead

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.

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¶

We build rather than resell, so no license margin is steering this either way. If the framework above points you at something you can buy, run it and buy it; we would rather say so than talk you into building something you should not build. What we do not do is take on the shortlist, the vendor selection or the license negotiation, and we do not promise a written buy recommendation as an output of discovery.

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.