Most custom systems start with a frustration. The spreadsheet that three people edit at once and nobody trusts. The job sheet that gets typed up twice. The customer who calls to ask where their order is because nobody can tell them without checking four places. Scoping a custom business system properly starts with frustrations like these.
At some point, someone says “we need a system for this”. That’s often true. But the jump from frustration to a working system is where many businesses lose money, because they start building before they’ve properly worked out what they need.
Scoping is the process of turning “we need a system” into a clear description of what the system should do, for whom, and why. You don’t need to be technical to do it well. In fact, the people who understand the business are usually better placed than developers to get this part right.
Check whether you need custom at all
Before anything else, look at what already exists. Off-the-shelf software has improved enormously, and there are specialist tools for most industries. A custom business system costs more to build and needs looking after for its whole life.
Custom development usually makes sense when:
- Your process is genuinely different from how the software on the market assumes you work, and that difference matters to your business.
- You need several existing tools to talk to each other and there’s no simple way to connect them.
- You’ve tried off-the-shelf options and spend more time working around them than using them.
- The system itself is part of what makes you better than competitors.
Sometimes the answer is in between: an off-the-shelf platform with some custom integrations or a small custom tool that fills a specific gap. Keep that option open.
Map the current process
Write down how the work actually happens today, step by step. Not how it’s supposed to happen, how it really happens. Talk to the people who do it. You’ll almost always discover workarounds, duplicate data entry and informal steps that nobody mentioned.
For each step, note:
- Who does it.
- What information they need and where it comes from.
- What they produce and who it goes to.
- What tools they use: paper, spreadsheet, email, software.
- Where it goes wrong or slows down.
A simple flowchart on a whiteboard or a numbered list is plenty. The goal is a shared understanding of the process as it is, including the messy bits.
Define the problem and the outcome
With the process mapped, write down the specific problems you want to fix and what success looks like. Try to be concrete. “Save time” becomes “stop typing job details into two systems” or “let customers check order status without calling us”.
If you can, estimate the current cost of each problem in time or money. It doesn’t need to be precise. If three people spend an hour a day on double data entry, that’s a real number you can compare against the cost of the system. It helps you decide what’s worth building and keeps the project honest.
Identify the users and what each needs
List everyone who’ll use the custom business system, grouped by role. For each role, describe what they need to do in simple sentences. A common way to write these is as short statements, for example:
- As an office manager, I need to assign jobs to engineers so that everyone knows their schedule.
- As an engineer, I need to see my jobs on my phone so that I don’t need to call the office.
- As a customer, I need to see when my engineer is booked so that I can plan my day.
This format keeps the focus on what people need to achieve, rather than on buttons and screens. It also makes it easier for developers to estimate accurately.
Think about permissions too. Who should see what? Who can change or delete information? These questions have a big impact on how a system is built.
Prioritise ruthlessly
Once you’ve listed everything the system could do, sort it. A common approach is:
- Must have: without this, the system doesn’t solve the core problem.
- Should have: important, but the first version can work without it.
- Could have: useful ideas for later.
- Won’t have (this time): explicitly out of scope.
The first version should contain only the must-haves. It’s tempting to build everything at once, but a smaller first release gets into people’s hands sooner, costs less and shows you what’s actually needed. Many “essential” features turn out to be rarely used once people start working with the real thing.
The most expensive feature in any custom business system is the one you built but didn’t need. Scope small, release, learn, then add.
List the data and integrations
Note what information the system will store, where existing data lives and whether it needs moving across. Data migration is often underestimated, especially if the current data is inconsistent or spread across several spreadsheets.
List every other system it needs to connect to: accounting software, CRM, email, payment providers, your website. For each, note what information needs to flow and in which direction. Integrations can be simple or complex depending on what the other system allows, so a developer will want this detail early.
Think about the whole life of the system
A custom business system isn’t finished when it launches. Before committing, ask:
- Who will host it, and what will that cost each year?
- Who fixes it if it breaks, and how quickly?
- How will security updates be handled?
- Who owns the code and the data? Can you move to another developer if you need to?
- How are backups handled, and have they been tested?
- If it holds personal data, how will data protection responsibilities be met?
Get the answers in writing. Ongoing support should be part of the budget from the start.
Custom business system scoping checklist
- We’ve checked whether off-the-shelf software or a hybrid could do the job.
- The current process is mapped step by step, including workarounds.
- Specific problems are written down, with a rough cost for each.
- We know what success looks like and how we’ll measure it.
- Every user role is listed with what they need to do.
- Permissions are thought through for each role.
- Features are prioritised, and the first version contains only must-haves.
- Data sources and any migration needs are listed.
- Required integrations are listed with what data flows where.
- Hosting, support, security and backups are planned and budgeted.
- Ownership of code and data is agreed in writing.
- People who’ll use the system have reviewed the scope.
Taking the next step
A well-prepared scope for a custom business system makes conversations with developers much more productive and quotes far more reliable. If you’d like help with the scoping itself or the build that follows, have a look at our custom development service, or our integrations work if the answer turns out to be connecting the tools you already have.
