It usually starts small. A spreadsheet that three people update at the same time. An order system that doesn’t talk to the warehouse. A process so specific to your business that no app on the market quite handles it. At some point, someone says, “Why don’t we just build our own?”
Sometimes that’s the right call. Custom software can fix problems that off-the-shelf tools never will. But it’s also a serious commitment. You’re signing up for development costs, a long build, and years of maintenance after launch.
Before you brief a developer or sign a contract, it pays to work through a few questions first.
Start with the problem, not the software
It’s tempting to begin with features: a dashboard here, an approval button there. A better starting point is the problem itself. What is slow, error-prone or impossible in your business today? Who feels that pain, and how often?
Write it down in plain language. “Sales and finance work from different numbers every month-end” is far more useful than “we need a new reporting module.”
Then split your list into must-haves and nice-to-haves. And be honest about one thing: is this a software gap or a process gap? Some problems disappear once a workflow is cleaned up or someone takes clear ownership. Software won’t fix a process nobody agrees on.
This is the decision that shapes everything else, and many businesses skip straight to “build.” In reality, there are three broad paths.
Off-the-shelf software. Ready-made tools are the fastest and cheapest way to get started. You pay a subscription and you’re up and running in days or weeks. The trade-off is that you adapt to the software, not the other way round. If your process is fairly standard, that’s often fine.
Customizing an existing platform. Many business platforms, including ERP, CRM and e-commerce systems, already handle the core of what most companies need. They can then be extended for the parts that are unique to you. Platforms like Odoo, for example, already cover sales, inventory, purchasing and accounting. So it’s often cheaper to look into customizing Odoo around your existing workflows than to build every one of those modules yourself. You get a proven foundation and only pay to develop the parts that genuinely differ.
A fully custom build. Building from the ground up makes sense when the process or product is truly unique, or when the software itself is part of what sets you apart from competitors. You get full control, but you also carry the full cost and responsibility.
| Option |
Upfront cost |
Time to launch |
Flexibility |
Maintenance load |
| Off-the-shelf |
Low |
Fast |
Low |
Low (vendor handles it) |
| Customized platform |
Medium |
Medium |
High |
Medium |
| Fully custom build |
High |
Slow |
Very high |
High (all on you) |
Most growing businesses end up somewhere in the middle: a solid platform for the standard work, with custom pieces only where they add real value.
Budget for the full life of the software, not just the build
The development quote is the number everyone looks at. It’s rarely the full picture.
Once the software is live, it needs hosting, security updates and bug fixes. Users will ask for changes. Staff will need training, and new hires will need onboarding. If the software connects to other systems, those connections need watching too, because the other systems change.
A useful habit is to plan a yearly maintenance budget from day one, before you’ve written a single line of code. If that figure makes the project look unaffordable, it’s better to know now than two years in.
Timeline and internal resources
Custom software isn’t something you hand over and collect a few months later. Your team will be involved throughout, answering questions, reviewing designs and testing early versions.
Decide early who owns the project internally. This should be someone who understands the process, has time set aside, and can make decisions without waiting a week for approval. Projects stall quickly without that person.
It also helps to know the usual phases: discovery, design, build, testing and rollout. Each one takes longer than people expect, testing especially. Rather than building everything at once, consider launching a smaller first version that solves the most painful problem. You learn far more from real users than from a requirements document.
Very few systems work alone. Your new software will probably need to connect with accounting, payment gateways, online marketplaces, HR or inventory tools.
List every system it needs to talk to, and what data moves between them. Ask your developer how each connection will be built, what happens when one side changes, and how errors will be flagged.
Don’t forget data migration. Moving years of customer records, products and transactions out of old systems or spreadsheets is often messier than the build itself. Poor integration and rushed migration are two of the most common reasons a project disappoints after launch.
Ownership, documentation and avoiding lock-in
This is the part people only think about when something goes wrong.
Who owns the source code once the project is paid for? Make sure it’s in writing. Is the system documented well enough that another developer could pick it up? And if your current developer becomes unavailable, what’s the plan?
Good documentation feels like a luxury during the build. It becomes essential the first time you need to change something.
Security, compliance and scalability
Any system that holds customer, financial or staff data needs proper access control. People should see only what they need for their role. Ask how data is protected, backed up and restored.
Check local requirements too, such as tax, invoicing and data protection rules in the countries you operate in. These are far easier to design for from the start than to bolt on later.
Finally, think three years ahead. Will the system cope with more users, more branches or ten times the transactions? You don’t need to build for that today, but the foundation shouldn’t block it.
How to choose the right development partner
The right partner matters as much as the right technology. A few things to look for:
- Relevant experience. Ask for examples of similar projects, ideally in your industry or at your company’s size.
- Willingness to push back. A good partner questions your requirements and suggests simpler options. One who quotes exactly what you asked for, without question, may not be thinking about your business.
- A clear process. How do they handle testing, sign-off, handover and support after launch?
- Honest advice on build vs. customize. If an existing platform can do 80% of the job, they should tell you, even if it means a smaller project for them.
A short first meeting with these questions will tell you a lot about how the project will go.
Final thoughts
Custom software can give a business a real edge, but only when it solves a clearly defined problem and the full cost is understood upfront. For many companies, the smartest path is to customize what already exists and build only what’s truly unique to them.
Taking the time to work through these questions before development starts won’t slow you down. It’s what keeps the project on budget and avoids expensive rework later.