Before you build: five questions that decide whether custom software will pay off
Custom software is a serious investment. These five questions separate the projects that earn their cost from the ones that become expensive maintenance.
Most businesses that ask us for custom software are right to ask. A few are not, and the difference is usually visible before any code is written. These are the questions we work through with every prospective client, and they are worth answering honestly on your own first.
1. What does the manual version cost today?
Put a number on it. Hours per week spent re-typing, reconciling, chasing, compiling. Multiply by the loaded cost of the people doing it. Add the cost of the errors that slip through: a missed order, a wrong invoice, a customer who left.
If that number is small, custom software is unlikely to pay for itself and a cheaper tool or a process change is the better answer. If it is large, you now have the budget conversation grounded in something real.
2. Is the process actually stable?
Software encodes a process. If the process changes every month because the business is still working out how it operates, software built today will be wrong by the time it ships. In that situation, a flexible tool (a well-structured spreadsheet, a low-code database, a configurable platform) buys time until the process settles.
Custom software is for processes you understand well enough to describe precisely.
3. Does an existing product cover eighty percent of it?
Be honest about the gap. If a mature product covers most of what you need and the remaining twenty percent can be handled by integration or a small extension, buy it. Building your own version of a solved problem is rarely a good use of money.
Custom becomes the right choice when the missing twenty percent is the part that makes your business different, or when the "almost fits" product forces your team to work around it every single day.
4. Who will own it after launch?
Software does not stop needing attention. Dependencies update, operating systems change, someone needs a new report. Before building, decide who is responsible for the system's ongoing health: an internal person, a maintenance agreement with the builder, or both. A system without an owner degrades quietly until it fails loudly.
5. What is the smallest release that changes something?
A project defined as "the new system" is a project that will take a year and disappoint. A project defined as "stop re-typing orders from the form into the accounting software" can ship in weeks, prove its value, and earn the next phase.
If you cannot describe a first release that a real person would use and be glad of, the scope is not ready.
Answering these with us
These are the same questions we ask in a discovery engagement. The difference is that we will also translate the answers into an architecture, a phased plan and an estimate you can hold us to. If the honest answer is "do not build this yet", we will say so; it is a cheaper conversation for both of us than the alternative.