The honest default for any business process is off-the-shelf software. Accounting, email, payroll, project tracking, customer relationship management: for all of these, excellent products exist, cost a predictable monthly amount and are maintained by someone else. Building your own version of them is almost always a mistake.
And yet custom applications get built every day, for good reasons. The trick is recognising when you have one of those reasons and when you are just frustrated with a tool you have not configured properly.
Signs that off-the-shelf is still right
- The process is a commodity. Invoicing, bookkeeping, email marketing, ticketing. Your way of doing it is not what makes your business different.
- The friction is configuration, not capability. The tool can do what you need; nobody has set it up. An afternoon with the documentation or a consultant beats a development project.
- There is no owner. Custom software needs someone inside the business who decides what it does and keeps deciding. Without that person it decays.
- The team is small and the volume is low. Manual steps that take an hour a week are cheaper than software for a long time.
Signs that custom is worth it
- The process is your differentiator. The way you quote, schedule, assemble, inspect or deliver is why customers choose you, and no product models it well.
- Spreadsheets have become the system. When the real workflow lives in spreadsheets passed between three tools, with people re-typing data at each step, the business is already running on custom software. It is just fragile and unversioned.
- You pay for seats and features you do not use because the only tool that covers your one unusual requirement is an enterprise suite.
- Data has to flow between systems that will not talk to each other, and the workarounds are manual.
- Customers or partners need a window into your operation: order status, documents, approvals, bookings. Portals are rarely off-the-shelf because every business exposes different things.
The middle path, which is usually the answer
Custom does not have to mean replacing everything. The most successful projects we see keep the commodity tools and build the one piece that is missing:
- An integration that moves data automatically between the tools you already pay for, so the spreadsheet disappears. (See our plain-language guide to integrations.)
- A portal that sits on top of your existing systems and shows customers or field staff exactly what they need.
- A single workflow tool for the one process that no product handles, with everything else left as it is.
Each of these is a fraction of the size of "build us a system", and each solves the actual problem.
Scoping a first version
If custom is justified, the biggest risk is building too much. A good first version:
- Covers one workflow end to end, not five workflows halfway. Pick the one that hurts most.
- Replaces the spreadsheet, not the accounting package. Keep the boundaries of the existing tools and connect to them.
- Has a named owner who tests it, decides on changes and says no to scope.
- Ships to real users early, even if rough, because what people actually do with it will change the plan.
- Has a maintenance arrangement from day one: who updates dependencies, where it is hosted, what happens when something breaks at 9 a.m. on a Monday.
What it costs is driven by the number of distinct screens and rules, the systems it has to connect to, and how much of the existing data has to be migrated. Those are the things to pin down in the brief; the technology choice follows from them.
Questions to ask whoever builds it
- Who owns the code and the data at the end? (You should.)
- Where will it run, and what does that cost per month?
- How are updates, backups and security patches handled after launch?
- What documentation and access do we get, so another developer could take over?
- What is the smallest version that would be useful, and could we start there?
A developer who answers those comfortably is one you can work with. If you would like to talk through a workflow and hear whether custom is the right answer for it, describe it to us in plain terms. Often the answer is a small integration rather than an application, and we will say so.