“Should we build custom software?” is usually the wrong first question. It assumes the answer before the problem has been measured.
Short answer: buy when the problem is common and a product fits. Automate when good systems fail only at the handoff. Build when a valuable, stable workflow is genuinely distinctive. Wait when the problem is infrequent, inexpensive or still changing.
Begin with the cost of the problem
Record how often the problem occurs, who is involved, how long it takes and what happens when it goes wrong. Include customer delay, correction work and dependence on key people—not merely the minutes spent typing.
If the annual cost is smaller than the likely remedy, you may already have your answer. A tolerable workaround can be economically rational.
Buy when the problem is common
Accounting, email marketing, basic scheduling and standard ecommerce are mature product categories. A specialist vendor spreads development, support and compliance costs across thousands of customers. Rebuilding those capabilities for one business is rarely sensible.
Buy when an existing product handles the important eighty percent, its limitations are manageable and adoption is more valuable than perfect fit.
Automate when the systems are good but the handoff is bad
Many “software problems” are actually transfer problems. A form creates an enquiry, someone copies it into a CRM, another person creates an invoice and the customer receives an update manually. Each system may be adequate; the joins are expensive.
A good automation moves structured information, records what happened and gives a person a clear queue for exceptions. Automation without exception handling merely makes mistakes faster.
Build when the mismatch is valuable and stable
Custom software makes sense when the process is central to how the business earns money or delivers its service, no existing product handles it adequately, and the rules are understood well enough to encode.
Start with the smallest useful path. A focused job tracker or customer approval flow can remove the bottleneck without recreating CRM, accounting and document storage from scratch.
Wait when uncertainty is the real problem
Do not automate a process that changes every week. Do not build for a problem that has happened twice. Document the workflow, collect examples and establish the cost. Waiting is an active decision when it produces better information.
A simple scorecard
- Frequency: how often does this happen?
- Cost: what time, money or customer trust does it consume?
- Fit: how much of the important workflow does an existing product cover?
- Stability: will the rules still be true in six months?
- Ownership: is this workflow a genuine source of advantage?
High frequency, high cost, poor market fit and stable rules strengthen the case for a focused build. Good market fit strengthens the case for buying. A narrow handoff problem suggests automation. Low cost or unstable rules suggest waiting.
Get a second opinion before requesting quotes
A development quotation answers “what will this build cost?” It does not necessarily answer “should this be built?” Use the free Build, Buy, Automate or Wait Review to test the decision first, or compare likely ranges on our published pricing page.