Is custom software always more expensive?

Over three years, often not - but the comparison has to include implementation, per-seat growth, the modules sold separately, and the staff time spent bridging gaps. At year one the packaged option is almost always cheaper, and if the fit is good it stays cheaper.

How long does a custom build take?

A focused internal system is typically eight to fourteen weeks to production. A multi-module platform is longer and should be delivered in stages, with the first module live while the next is being built. If nothing reaches production before month nine, ask why.

Can we start with a package and move to custom later?

Yes, and it is often the sensible path. Using something packaged clarifies requirements at low cost. The one thing to protect is your data: make sure you can export it completely, in a documented format, before you depend on the system.

What happens if the developer disappears?

This is the right question to ask and the answer should be structural, not reassurance. You own the repository, the deployment is documented, the stack is mainstream rather than exotic, and no runtime licence binds you. Those four things mean another team can pick it up.

Buying software

Custom Software vs Off-the-Shelf: How to Actually Decide

Most of this decision gets made on price and regretted on fit. Here is the way to run it properly, including the cases where we tell people not to build.

19 September 2026 8 min read Plexowave

We build custom software, so treat what follows with the scepticism it deserves. It is still true that most businesses asking us this question should buy rather than build, and the ones who should build usually know why before they call - they just want someone to confirm that the thing they cannot find does not exist.

The decision is usually framed as cost. That framing is wrong, because the two options have costs of different shapes. Packaged software has a low, certain, recurring cost and an uncertain fit. A custom build has a high, uncertain, one-off cost and a fit you specify. Comparing the first number to the first number tells you almost nothing.

The four questions that decide it

Run these in order. The first one that gives a clear answer usually ends the argument.

Is the process a competitive advantage, or just necessary?Payroll is necessary. Nobody wins business by running payroll unusually well, so buy it. The way you cost a job, match a lot to a buyer, or schedule your machines might genuinely be how you compete - and encoding that into someone else's workflow is how you stop competing on it.
Can a packaged product express your data model?Not your screens - your model. If your stock has two units that must both stay true, if goods can be yours while physically elsewhere, if a worker is paid three different ways in the same month, then a system with one quantity field and one salary structure will be wrong in a way configuration cannot reach.
How many packages would it take?One good package beats a custom build most of the time. Four packages plus the spreadsheets that join them almost never does - you have bought four fit problems and built an integration project without calling it one.
Who is going to own it in three years?A custom build needs someone accountable for it, whether that is an internal developer, a retainer, or another studio. If the honest answer is nobody, buy something with a support contract instead. Unmaintained custom software becomes a liability faster than unmaintained anything else.

The costs people miss on each side

On the packaged side, the recurring licence is the visible cost and rarely the largest one. The hidden costs are per-seat pricing that grows with headcount, the modules that turn out to be separate products, the implementation partner, the annual uplift, and the work your team does to bridge the gap between what the software does and what you need - which is a permanent staffing cost that never appears in the comparison.

The largest packaged cost is usually the one nobody prices: the processes you change to fit the software. Sometimes that is a benefit, because the packaged process is better than yours. Sometimes it means your best people spend their week doing data entry that exists only to keep the system happy.

On the custom side, the build is the visible cost and it is usually estimated honestly. What gets underestimated is data migration, the parallel run, and the year-two changes. Migration is almost always worse than it looks, because the old data contains a decade of exceptions nobody documented. A parallel run is not optional and it is not free - somebody does the work twice for a month. And software that cannot change is software you will replace, so budget for change rather than treating it as failure.

The hybrid nobody proposes

The framing is rarely all-or-nothing in practice, and the best answer is often to buy the commodity and build the differentiator. Keep the packaged accounting system as the statutory book of record. Build the operational system that knows your trade, and post to accounting automatically.

This works because it puts the boundary in the right place. The accounting rules are the same for everyone and change by legislation; the operational rules are yours and change when you decide. Trying to make one system do both is what produces the worst version of each.

When we tell people to buy

A standard need with a mature market. Accounting for a single-entity business, email, payroll for salaried staff, document storage, general-purpose CRM for a small team selling a simple product. These categories have products refined over decades against thousands of customers. We cannot beat that in twelve weeks and neither can anyone else.

An unclear problem. If the requirement cannot survive a conversation with the people who will use it, a build will produce an expensive version of the confusion. Buying something cheap and living with it for six months is a legitimate way to discover what you actually need, and a much cheaper one.

No owner and no budget for year two. A build with nobody to maintain it decays into exactly the legacy system the project was meant to replace, except now it is one only you have.

When building is clearly right

You have tried packages and each failed in the same place. That place is usually your data model, and it will keep being the failure point, because it is the one thing configuration cannot change.

The software is the product, or is what the customer experiences. Nobody differentiates on a platform their competitors can also subscribe to.

The integration work would exceed the build. When four systems must agree and the joining is done by people and spreadsheets, you are already paying for a custom system - just in salary rather than in software, and without getting the software.

Compliance or data residency makes the packaged option genuinely impossible. This is less common than it is claimed, so check whether it is a real constraint or a preference - but when it is real, it is decisive.

How to test the decision before committing

Write down the three things your current process does that you believe no package handles. Then spend a day genuinely trying to make one package do them. Most objections do not survive this, and the ones that do are your real requirements.
Ask any vendor for a reference in your specific sector, and ask that reference what they had to change about how they work. The answer is the fit gap, stated by someone with no incentive to minimise it.
Price the packaged option at three years including implementation, uplift and the staff time to bridge gaps - not at year one licence cost.
For a build, insist on a phased plan where something real is in production inside three months. If the first delivery is at month nine, the risk is being deferred rather than managed.

The short version

Buy the commodity. Build the thing you compete on, if you have someone to own it. Be suspicious of anyone - including us - who answers this question before understanding your data model, because that is where the answer actually lives.