We build custom software for a living, and we still talk clients out of it fairly often. A practical test for whether a ready-made tool will do the job, and the signs that custom work is worth paying for.
It may seem odd for a software company to say this, but a fair number of the projects people bring to us do not need custom software. A ready-made tool would do the job better, sooner and for far less money. We would rather tell you that at the start than take your budget and hand you something you did not need.
Here is the test we use. Write down what the software has to do, in plain sentences. Then ask whether a business like yours, somewhere else in the world, would describe the same needs. If a school, a clinic, a shop and a courier company would all write roughly the same list, then the problem has been solved many times already and a product exists for it. Accounting, basic billing, email marketing, appointment booking for a single-location clinic, simple online stores and standard websites all fall into this group.
Ready-made tools have real advantages. They are cheaper to start with, since you pay a subscription instead of a build cost. They work the day you sign up. They are maintained and secured by a team whose whole job is that product. And they have been tested by thousands of users who found the bugs before you did. Building custom means paying for all of that yourself, and then paying to keep it working.
They also have limits, and knowing them is what separates a good decision from a hopeful one. Watch for these signs that a ready-made tool is not enough. You keep bending your process to fit the software, rather than the other way round. You are running the business partly in spreadsheets because the tool cannot do one important thing. You are paying for several tools that do not share data, so someone retypes information between them every day. Or the way you work is your competitive advantage, and a generic tool would flatten it.
Those situations are where custom software earns its cost. A business with an unusual approval process, a pricing model that depends on many variables, a workflow that spans several departments, or a need to connect systems that were never designed to talk to each other, is a good candidate. The value is not in having something bespoke. It is in removing work that people currently do by hand, and doing it accurately every time.
There is also a middle path that is often the best one. Start with a ready-made product for the standard parts and build only the piece that is genuinely specific to you, connected to the product through its API. You get a working system quickly, you spend your development budget where it counts, and you avoid rebuilding something that already exists.
Before you commission anything, do two things. First, list the manual steps that cost your team the most time each week and estimate what that time is worth. If the annual cost of the workaround is smaller than the cost of building and maintaining a replacement, do not build. Second, ask who will look after the software once it is live. Custom software needs updates, security fixes and occasional changes for years, and that cost belongs in the budget from day one.
When you do bring a project to us, we will start by asking what problem it solves and how you handle it today. If the honest answer is a tool you can subscribe to this afternoon, we will say so.