When your business needs a custom system — not another spreadsheet

A spreadsheet is often the right place to begin. It is quick, familiar and flexible enough to let a team discover what the process actually is before anyone pays to formalise it.

The problem is not that spreadsheets are primitive. The problem begins when a temporary working document quietly becomes the place where a business runs: orders, approvals, customer records, stock, schedules or money, all held together by memory and careful copying.

At that point the question is not whether custom software would look more professional. It is whether the current process is still safe, visible and economical to operate.

The signs that the tool no longer fits the job

The same information lives in several places. A customer name is copied into a sales sheet, an operations sheet and a finance sheet. When it changes, nobody knows which version is current. The work becomes reconciliation rather than progress.

The process depends on one person remembering the next step. A file cannot reliably own a handoff. If the person who knows the sequence is away, work waits or moves forward without the context the next person needed.

Permissions have become awkward. People need to see one part of a record but not another, or they may update a status without changing a price. Giving someone access to a whole document is not the same as giving them the access their role requires.

Reporting means rebuilding the truth every time. If a weekly answer requires gathering files, fixing formats and asking which rows are current, the report is exposing a data problem rather than solving it.

Errors are discovered late. A missing field, duplicate record or impossible status is easy to enter and hard to notice until another person relies on it. The later an error appears, the more work has grown around it.

A spreadsheet stops being cheap when people spend their time protecting it from the work it was meant to simplify.

First decide whether the process is the problem

Software makes a clear process repeatable. It does not make an unclear process correct.

Before replacing anything, sit with the people doing the work and follow one real case from beginning to end. Record what arrives, who decides, what changes, where the information moves and what happens when something goes wrong. Pay particular attention to the workarounds. They often describe the real process more accurately than the written procedure does.

If two people complete the same task differently, that is not yet a software requirement. It is a decision the business has to make. Building before resolving it simply turns the disagreement into a permanent feature.

Build, buy or connect what you already have

Custom software is only one of three reasonable answers.

•Buy when the process is standard and an established product already handles it well. Payroll, basic accounting and common sales workflows rarely become more valuable because they were rebuilt from scratch.

•Integrate when the tools are individually useful but people are copying information between them. The missing piece may be a reliable connection, not a replacement.

•Build when the workflow is specific to how the business delivers value, when existing products force costly workarounds, or when customers and staff need one experience that the current collection of tools cannot provide.

A good discovery phase can end with less custom work than expected. That is a successful result. The goal is to remove operational friction, not to maximise the amount of software in the building.

What the first version should actually do

The first useful version is usually smaller than the wish list. It needs to establish a dependable core:

•One source of truth. Each important record has one home, a clear owner and a visible history.

•Roles and permissions. People can see and change what their work requires, without receiving access to everything else.

•A defined workflow. The system knows the valid next steps, keeps the context with the work and makes stalled items visible.

•Connections at the boundaries. Information reaches the other tools that still have a job to do, without somebody retyping it.

•Useful exceptions. Unusual cases can be reviewed and resolved instead of being forced through the happy path or handled in a private side sheet.

That foundation is more valuable than a long list of screens. A small system that people trust will tell you what to build next. A large one based on assumptions will tell you only what you guessed wrong.

Migration is part of the product

Moving the old data is not a final administrative task. It is where years of inconsistent names, duplicated records and undocumented rules become visible.

Decide early what deserves to move, what should remain as a read-only archive and what can be discarded. Test the move with a copy of real data, check totals and relationships, and have the people who use the information verify that important cases still make sense.

The same principle applies to rollout. Running two systems indefinitely creates two versions of the truth, but switching everyone at once without training creates a different kind of risk. Plan the transition by team or workflow, give people a clear place to report problems and decide who owns the system after launch.

Questions to answer before asking for an estimate

You do not need a technical specification. You do need a business description that is concrete enough to test:

•Who uses the process, and what is each person responsible for?

•What starts the work, and what does done mean?

•Which decisions require approval, and by whom?

•Which information is sensitive or restricted?

•What other tools must receive or provide information?

•Which exceptions happen often enough to design for?

•What would become faster, safer or more visible if the project worked?

Those answers are enough to begin scoping. They also make it easier to challenge a proposal that solves an interesting technical problem while missing the operational one.

Start with the work, not the software

The best custom systems feel unsurprising to the people who use them. They follow the work closely enough that the software removes decisions people should not have to repeat, while leaving genuine judgement with the person responsible for it.

That is how we approach custom software and systems integration: understand the process as it operates today, decide what should be bought, connected or built, and put the scope in writing before development begins.

If your business is being held together by spreadsheets and careful people, tell us where the handoffs are breaking. We can help work out whether you need a new system, a connection between the tools you already have, or simply a clearer process.