The request usually arrives as a conclusion. We need a new system. Sometimes that is right. More often the business has a process problem that a subscription is being asked to solve, and twelve months later they have the same problem plus another monthly bill and a login nobody uses. The decision deserves better than a demo.
01. Describe the problem in money or hours first
Before evaluating anything, finish this sentence: this costs us ___ hours a week, or ___ dollars a month, and here is how we know. If you cannot fill in the blank, do not buy anything yet — not because the problem is not real, but because you have no way to judge whether a solution was worth it, and no way to choose between two that both demo well.
This step also catches the most common mistake, which is buying software to paper over an undefined process. Software makes an existing process faster and more consistent. It does not invent one. If three people each handle a job differently, a new tool will simply record three different approaches more efficiently.
02. Buy when the problem is ordinary — and it usually is
Accounting, payroll, scheduling, invoicing, email, storage, most CRM: these are solved problems, and off-the-shelf software solves them better and far cheaper than anything custom, because the vendor amortises development across thousands of businesses and handles security, updates and compliance while you sleep.
Be honest about whether you are actually unusual. Almost every business believes its scheduling is uniquely complicated. Most are not — they are simply accustomed to their own version of it. Ask instead: is this difference something clients pay us for? If yes, protect it. If it is just habit, adapt the habit and take the cheaper tool. Adapting is uncomfortable for a fortnight and cheaper for a decade.
03. Build only where the difference is the business
Custom software earns its cost in a narrow set of cases: when the process genuinely is your competitive advantage, when nothing on the market fits without contortion, when the integration between systems you already own is the actual product, or when the per-seat cost of a packaged tool has grown past what building would cost outright.
Go in with the full number, though. Building is not a one-time expense — it is development, then hosting, then maintenance, then someone to call when it breaks at 7pm, for as long as you use it. Custom software is a pet, not a purchase. That is entirely worth it when the thing it does is the thing you are paid for, and a slow leak when it is not. When we build for clients, that conversation happens before the estimate, not after.
04. The third option nobody offers you
Leave it alone. Not every inefficiency is worth removing. A task that costs two hours a month does not justify a system that costs six hours to maintain, and a business running eleven tools where six would do has usually solved a series of small problems by creating one large one.
The integration question is the tiebreaker most owners underweight. A merely adequate tool that connects cleanly to what you already run will beat an excellent tool that stands alone, because the cost of disconnected systems is paid daily in re-typing, reconciliation, and mistakes. Before you buy, ask how it talks to the rest of the stack — and if the honest answer is “export to CSV,” treat that as a price, not a feature.
Problem in hours or dollars, then buy, build, or leave it. In that order, every time.
If you are staring at a demo and cannot tell whether it solves the real problem, that is what we are for — schedule a consultation.