"Should we build our own software?" is one of the most consequential technology questions a growing business faces. Build too early and you spend heavily on something an existing product already does well. Wait too long and your team spends years working around tools that do not fit.
Here is a practical way to make the decision.
Start with the default: buy
For common business functions — accounting, email, payroll, standard CRM, helpdesk, project management — established software products are usually the right answer. They are mature, maintained by someone else and often inexpensive relative to building.
A custom application needs to justify itself against that default.
Signals that custom software may be worth it
Your process is a competitive advantage
If the way you deliver your service is what makes customers choose you, forcing it into a generic tool can erode that advantage. Custom software lets you encode your method.
You are paying for workarounds
Look at how much time staff spend exporting, re-typing, reconciling spreadsheets and chasing updates between tools. When the cost of workarounds exceeds the cost of a focused application, building becomes economical.
Your tools do not talk to each other
A business running on five subscriptions that share no data often benefits from a central application — or integrations — that becomes the single source of truth.
Customers need self-service
If customers regularly contact you for information you already hold — order status, documents, appointment details — a portal can reduce workload and improve their experience.
Off-the-shelf options are close but not enough
Sometimes an existing product covers 80% of your needs, and the remaining 20% is where the value is. Extending a product through its API, or building a small companion application, may be better than a full custom build.
Signals that you should not build (yet)
- The process is still changing every month. Stabilise it first, or use flexible tools while you learn.
- Nobody can describe the workflow clearly. Document it before writing software.
- There is no owner. Custom software needs someone to make product decisions and prioritise improvements.
- There is no maintenance budget. Applications need security updates, hosting and improvements. Plan for it from the start.
- A configurable product already fits. Admitting this early saves money.
Understand the full cost
The initial build is only part of the investment. Consider:
- Discovery and design to define what to build.
- Development and testing of the first release.
- Hosting and infrastructure.
- Maintenance: dependency updates, security patches, bug fixes.
- Improvements as your business evolves.
- Internal time for decisions, testing and training.
Compare this with the full cost of the alternative: subscriptions, per-user fees, the time spent on workarounds and the opportunity cost of slower operations.
Reduce the risk of a custom build
Begin with discovery
A short discovery phase maps the workflow, identifies the most valuable problems and defines a first release. It often reveals simpler solutions — and when it does not, it gives the build a clear direction.
Build a focused first release
Resist building everything at once. Solve the most painful part of the workflow first, put it in front of real users and improve based on what you learn.
Prototype before you build
Clickable prototypes let users try the workflow before development starts. Changing a prototype costs far less than changing working software.
Insist on fundamentals
Any custom application handling business data should include role-based access control, secure authentication, validated input, automated tests for critical paths, backups and clear deployment documentation.
Plan for ownership
Agree on code ownership, documentation and handover upfront, so you are not dependent on a single person or vendor for the future.
A simple decision framework
Answer each question with yes or no:
- Does a well-regarded existing product meet at least 90% of our needs? (If yes, buy.)
- Is the workflow stable and clearly understood?
- Are workarounds costing significant staff time every week?
- Would the application create a better experience for customers or a real operational advantage?
- Do we have an owner and a maintenance budget?
If the answer to question 1 is no, and questions 2–5 are mostly yes, a custom web application is likely worth exploring.
Next steps
Write down the workflow as it happens today, estimate the weekly time spent on manual steps and list the tools involved. That information makes a build-versus-buy conversation concrete.
If you would like an objective view — including a recommendation not to build if that is the right answer — get in touch with us.
