When does a business need a bespoke system, and when would better use of existing tools be enough?

Start with the last difficult case, not a feature list.

Choose an order, report or request where something went wrong. Reconstruct the steps: where information appeared, who changed it and when someone noticed the problem. Also record what the team had to do to put things right.

If the cause was a lack of agreed responsibility, new software will not establish it on its own. If two people edited different versions of a file and nobody can identify the correct one, the tool may genuinely be limiting the process. Making that distinction helps avoid recreating the same confusion digitally.

• What exactly happened?
• How often does a similar situation recur?
• What information or rule could have prevented it?

First signal: the answer depends on whom you ask.

The salesperson gives a different date from the planner. The warehouse stock figure differs from the customer service spreadsheet. A manager waits for the only person who knows where the current file is. The problem is not the appearance of the table, but the absence of a shared source of information.

Check whether one system can be made responsible for each important piece of data. Sometimes organising existing tools is enough. A bespoke module becomes justified when information needs to pass through several roles and the available tools cannot handle the required changes and confirmations.

• Identify the owner of statuses, dates and customer data.
• Agree who can change that information and where they should do it.

Second signal: the rules work only because employees remember them.

A batch must be checked before dispatch, a quotation approved again after a quantity change, or an extra document added for a particular order. If these rules exist only in a few people’s heads, the next absence or new employee exposes the risk.

Write the conditions as “if X happens, we need Y”. Add an exception to every rule. Only then can you assess whether a configured standard product, simple automation or a system with its own workflow is needed. Not every exception immediately requires a separate feature; some can be passed to an authorised person.

Compare three routes using the same scenario.

Do not compare an off-the-shelf product with a wish list for a custom application. Prepare one representative process and test it in each option: reorganised existing tools, an available product and a bespoke solution. Look at manual workarounds, data exports, integrations and the training the team will need.

Your own system offers room to tailor the solution, but requires design decisions, maintenance and further development. A standard product may get work started sooner, but its rules, access costs and limitations need to be understood before choosing it. A mixed approach often preserves what already works while filling only the missing workflow.

• Can the process be completed from beginning to end?
• What still needs to happen outside the tool?
• How will we retrieve our data, and who will maintain the solution?

Account for the cost of today’s work and tomorrow’s change.

Gather examples from a representative period. Separate active working time from waiting for a decision. Fifteen minutes of copying and several days of waiting are different problems, even when both delay the customer. Record corrections, duplicates and situations requiring several people as well.

For the new solution, include analysis, development, integrations, migration, user onboarding and maintenance. Some benefits may concern better control rather than direct staffing savings. It is worth naming that benefit instead of assigning a seemingly precise return on investment to every feature.

The first version should complete one workflow.

For a quotation process, that might mean receiving an enquiry, preparing a quote version, recording a decision and handing the approved case over to delivery. A complete flow can be assessed in practice. Customer, document and settings screens without connections between them do not yet demonstrate a useful system.

Define what stays outside the first stage. Advanced analytics may wait, but failing to handle a rejected quotation will probably interrupt daily work. Choose scope according to process completeness, not how impressive a feature looks during a presentation.

• Beginning: what starts the case?
• Middle: who takes action and makes the decision?
• End: what result means the work is complete?

Before deciding, agree who will own the system.

You need someone who can resolve questions about the process and priorities. Without that person, every suggestion can change the project’s direction. Include future users in the conversation too: their everyday exceptions often do not fit into the description prepared by management.

Agree how acceptance will work: several specific scenarios with expected results, named testers and sample data. Discuss updates, backups, access to documentation and arrangements for further development. The decision to build software covers its entire working life, not just launch day.