Custom software or off-the-shelf: how to decide

Most small businesses ask the wrong question first. They ask “should we build custom software or buy a ready product?” when the useful question is “which parts of how we work are actually unusual, and which parts are the same as every other business in the country?” Answer that honestly and the software decision mostly makes itself.

This post is a way to think through the choice. There is no universally correct answer, and any vendor who gives you one without asking about your process is selling, not advising.

Start by separating your processes into two piles

Take a sheet of paper and list the things your business does that involve records, approvals, or repeated data entry. Payroll. GST invoicing. Attendance. Lead follow-up. Purchase orders. Dispatch. Service complaints. Whatever applies.

Now split that list into two piles.

Pile one is everything where you do it more or less the way every other business does it. Your GST invoice looks like everyone’s GST invoice because the law says so. Your salary slip looks like everyone’s salary slip. Your email works like everyone’s email. There is nothing clever about your approach here and no customer has ever chosen you because of it.

Pile two is everything where your way is genuinely different, and the difference is why customers stay. A fabrication shop that quotes jobs using a costing logic the owner refined over twenty years. A distributor whose credit terms vary by customer history in a way no standard accounting package models. A diagnostics lab that routes samples between three collection centres on rules nobody else uses.

Off-the-shelf software is almost always the right answer for pile one. Custom software earns its cost only in pile two, and even then only sometimes.

The expensive mistake is building custom software for pile one items. Businesses do it constantly. Somebody decides the existing accounting package is “not exactly how we work”, spends six months and a serious amount of money building a replacement, and ends up with something that does eighty percent of what the ready product did, has no support team, and breaks the next time the GST portal changes a field.

When off-the-shelf clearly wins

Buy ready software when the process is standard and regulated. Compliance software in particular. When filing formats change, a product company updates for its entire customer base and you get the update. With custom software, every change is a fresh scope discussion and a fresh bill.

Buy ready when your team is small and you need something working next week. A ready product can be live on Monday. Custom software, done properly, involves requirement discussion, design, build, testing and training. That is weeks at minimum, months for anything substantial.

Buy ready when the problem is well understood and you have no strong opinion about how it should be solved. If you cannot describe, in specific terms, what the ready product does wrong, you do not have a custom software requirement. You have a training requirement.

Buy ready when you want someone else to carry the maintenance burden. Product companies have support teams, documentation, and other customers reporting bugs before you hit them. That has real value and it is easy to undercount.

When custom starts to make sense

Custom software makes sense when the process is the advantage. If your quoting logic, routing rules, or pricing structure is the reason customers choose you, forcing it into a generic product means either compromising the process or maintaining a shadow system in Excel alongside the software. Many businesses end up in exactly that state: paying for a product and still running the real business out of spreadsheets on one person’s laptop.

Custom also makes sense when per-user licence costs scale badly. This is the one that catches growing businesses. A per-user, per-month subscription looks trivial at five users. At sixty users across three branches, plus add-on modules, plus the premium tier you needed for one specific report, the annual figure can cross what a custom build would have cost. Do this arithmetic before you sign, not after.

The pattern to watch for is a business where most users need the software for one small thing. A warehouse where forty people only need to scan and confirm dispatch should not be paying full seats for forty people. Sometimes the answer is a small custom tool sitting alongside the ready product, not a full replacement. A simple internal app that handles the one high-volume task and pushes data into the main system is often the cheapest good answer, and it is a common shape of work in our software solutions projects.

Custom also makes sense when integration is the actual problem. If your staff spend hours moving data between three systems by hand, a custom layer that connects them can pay for itself faster than replacing any of the three.

Total cost of ownership, honestly

Compare the full picture over three to five years, not the first invoice.

For off-the-shelf, count subscription or licence fees at your expected user count, not today’s count. Add module upgrades you will probably need. Add implementation and data migration if the vendor charges for it. Add the cost of the workarounds: if four people spend an hour a day in Excel because the product does not do something, that is a real recurring cost.

For custom, count the build, then add the parts people forget. Hosting. Backups. Someone to call when it breaks. Changes when the business changes, and the business will change. Retraining when staff leave. A custom system with no maintenance budget quietly rots, and in three years someone says “the software does not work properly any more” when what actually happened is that nobody maintained it.

A reasonable rule of thumb: assume custom software needs an ongoing annual maintenance budget as a normal cost of ownership, the same way a delivery vehicle needs servicing. If you cannot commit to that, buy ready.

Lock-in and getting your data out

Ask both types of vendor the same question: if we leave, how do we take our data with us, in what format, and what does it cost?

For a ready product, check whether export is available on your plan or only on a higher tier. Check whether export includes attachments, historical records, and audit trails, or only the current master data. Check whether you can export on demand or have to raise a support request.

For custom software, ask who holds the source code and the database credentials, and get it in writing in the contract. Ask whether the system runs on infrastructure you can access. This matters more than people expect, because the relationship with any vendor may end for reasons that have nothing to do with quality. Reasonable custom work leaves you with the code, the database, and documentation clear enough for a different team to pick up. If a vendor resists that, treat it as a warning.

Related question worth asking early: where does the system actually live? Whether it is your server, a shared host, or a cloud account in your company’s name changes how easily you can move later. We cover the practical side of that in servers and hosting.

The biggest risk is building something nobody uses

More custom projects fail from non-adoption than from bad code. The system works, it does what the specification said, and three months later staff are back to WhatsApp and paper because the software takes eleven taps to do what a phone call did in ten seconds.

Ways to reduce that risk:

Involve the people who will actually use it, not only the owner and the manager. The person entering data all day knows things about the process that never come up in a meeting.

Build the smallest useful version first and let people use it for a month before adding anything. Almost every long requirement list contains features nobody misses once they are removed.

Count the taps. If the software adds work for the person at the counter while saving work for the person in the office, the person at the counter will stop using it and your data will be incomplete.

Plan for phone use. In a lot of Indian businesses the field staff, the delivery team and the shop floor do not sit at desktops. If the workflow only works on a laptop, half your team is excluded. That is a large part of why mobile app work so often ends up being part of a custom software project rather than a separate thing.

A simple decision path

Is the process standard and regulated? Buy ready.

Is the process the thing customers pay you for, and does the ready product force you to compromise it? Consider custom.

Does the per-user cost of the ready product become uncomfortable at the size you expect to be in two years? Run the arithmetic before deciding.

Can you name three specific things the ready product does wrong, with examples from last week? If not, the answer is probably training, not software.

Can you fund maintenance for the next few years? If not, buy ready.

Mixed answers are normal and mixed solutions are fine. Plenty of well-run businesses use ready accounting software, a ready email platform, and one custom tool that handles the part of the business nobody else does the same way.

What to do next

Before you talk to any vendor, write down the two piles and the specific failures of whatever you use today. Bring that to the conversation. It will tell you more about the vendor’s honesty than any demo, because a good one will point at half your list and say “you do not need custom software for that.”

If you want a second opinion on where your own line falls, get in touch with Spier Infotech and describe the process rather than the software you think you want. Sometimes the answer is a build, sometimes it is a small tool next to what you already have, and sometimes it is nothing at all.