Questions we answerProcess and ownership
Should we build custom software or buy something off the shelf?
At this size, almost always buy. The cost that sinks small-business builds is not the build — it is owning it in year two without a developer.
Free · a few minutes · starts from “Something in the team isn't working”
The short answer
Almost always buy, at this size. The cost that sinks small-business builds is not the build, it is year two: owning software with no developer on staff, when the person or agency who wrote it has moved on. Build only where the process genuinely differentiates how you make money, where nothing available comes close after you adjust the process, and where you can fund maintenance indefinitely. Otherwise adapt to a product, or switch on what you already pay for.
Every page competing for this question is published by a firm that gets paid to build custom software. They produce balanced-looking frameworks whose criteria — differentiation, unique workflows, scalability — are drawn so that a motivated reader concludes build.
The criterion they leave out is the one that decides it. Software is not a purchase, it is a dependency: something has to keep working when the platform underneath it changes, when a rule changes, when the person who understands it leaves. A small business without a developer has no answer to that, and the absence only shows up long after the invoice is paid.
Is it really this?
Worth checking before you spend anything. These are the signals that tend to tell the two apart.
Signs it is
- The process is genuinely differentiating, not merely unfamiliar to the products you have seen.
- You have properly evaluated products against an adjusted process rather than against your current one.
- There is a credible answer to who maintains it in two years, and it is funded.
Signs it's something else
- No tool fits because the process has never been written down and is different each time.
- The appeal is that custom would do exactly what you do today, which is the thing most worth changing.
- The budget covers the build and nothing after it.
What's usually behind it
- A process that does not fit any product anybody has demonstrated.
- An accumulation of spreadsheets and manual steps that feels like it wants to be a system.
- A quote from a developer or agency that makes building sound close to affordable.
What people usually get wrong
- Treating the build quote as the cost. Maintenance, changes and the eventual rewrite are the expensive part.
- Assuming low-code or AI-assisted building removes the problem. It lowers the cost of creating something; it does not lower the cost of owning it.
- Commissioning software to preserve a process that only exists because of how something else is configured.
The options, and when each one fits
In no particular order. Which of these fits depends on your situation, not on the question you typed.
Buy a product and adapt
Something available covers most of it once you are willing to change how you work.
Configure what you already own
The capability exists in a system you pay for and has never been set up or switched on.
Fix the process first
Nothing fits because the process is undefined. Define it and most of the misfit disappears.
Commission a build
The process is genuinely core, nothing comes close, and maintenance is named and funded.
When doing nothing is the right call
Continuing with the awkward manual version for another quarter, while writing down what it actually does, is frequently the right call. It costs some patience and it is the only way to find out whether the requirement is stable enough to build anything against.
What the diagnostic asks
- What is going wrong today and how long it has been going on.
- How repeatable the process is and how much of it is written down.
- Who owns it, and whether software already exists for it.
- What a mistake costs and how sensitive the information is.
“I don't know” is always an answer. Nothing is assumed on your behalf.
The routes it weighs
Every diagnostic weighs all ten routes. These are the ones that tend to matter for this question — a description of the rules, not a promise about your answer.
Process improvement
Change how the work flows — remove steps, name an owner, fix the hand-offs.
Do nothing yet
Record the issue, set a revisit date, and decide what would change your mind.
Specialist support
Bring in a freelancer, consultant or specialist for a defined piece of work.
Outsource
Hand a defined, ongoing scope of work to an external provider.
AI Assist
Keep a person in charge and give them AI for drafting, summarising, checking or analysis.
Redistribute
Move ownership of the work to where it fits, and make that explicit.
What changes the answer
- A process that is genuinely how you compete is the only strong argument for building.
- Not being able to name who maintains it in year two is the strongest argument against.
- A requirement that is still changing means anything built now is being built against a moving target.
Get your own read
A handful of short questions, then the strongest route for your situation, what's also credible, what we still don't know and what would change our view. No account, no setup.
Related questions
- Should I fix the process before hiring?Usually yes, at least far enough to know what the new person would own. It is cheap and quick, and it either removes the need or tells you exactly what to recruit for. It stops being sensible once it becomes a reason never to decide.
- Do I need a CTO?Not always, and not always yet. The question is what technical leadership the business needs over the next year or two — and whether that is a permanent seat, a fractional or interim leader, or capability grown from inside.
- We have too many tools. What should we cut?Count problems, not tools. Ten tools each doing one job cleanly are fine; three holding the same customer list are not.
- Who maintains our automations when they break?Whoever built it — and if they have left or are too busy, you do not have an automation, you have a liability nobody is watching.
- Is my business too small for a CRM?Often yes, for now. A CRM solves a handoff problem, not a memory problem — and a half-adopted one is a worse record than the spreadsheet it replaced.
- Nobody has written our processes down. Is that a problem?Only where a process runs regularly and one person knows it. Documenting everything is a project small teams abandon; documenting a broken process makes the bad version official.