Many working systems start life as spreadsheets
That isn’t a problem on its own. A spreadsheet can be quick, familiar and flexible. It can help a team understand the work before anyone knows whether a proper system is worth building.
The problem starts when the spreadsheet is no longer just helping the work. It has become the place where the work lives.
This is less about whether spreadsheets are good or bad. It’s about whether this particular spreadsheet has become too important, too easy to break or too difficult to manage by hand.
Improve the spreadsheet
This can be the right answer when the work is still simple, low-risk and understood by the people using it.
- The file is used by a small number of people.
- The process is still easy to explain.
- Mistakes are unlikely to create serious problems.
- A tidy-up would make the current way of working safe enough.
Consider a Day-1 Build
This is worth looking at when the spreadsheet is now carrying an important job the business relies on.
- Several people depend on the information being right.
- The spreadsheet has become a tracker, approval list or handover point.
- Reporting, updates or checks take longer than they should.
- The business would struggle if the file broke or disappeared.
When improving the spreadsheet is still the right answer
Sometimes the sensible next step is to improve what already exists.
That might mean tidying the layout, reducing duplicate columns, adding clearer validation, protecting important cells, improving formulas or agreeing who owns updates.
If the work is simple, used by a small number of people and does not create much risk when something is missed, a better spreadsheet may be enough.
There’s no point replacing a spreadsheet just because it’s a spreadsheet.
Signs the spreadsheet has become the wrong place for the work
A spreadsheet starts to become risky when it’s doing more than holding information.
Common warning signs include:
- only one person knows how it really works
- several versions exist in different places
- people copy information in from emails, forms or other systems
- reports take hours to prepare
- the team argues about which number is correct
- rows are used as a tracker, approval list or handover point
- mistakes are hard to spot until they cause a problem
- the file has become too important to lose
At that point, the business may not need a huge software project. It may just need a clearer home for the work.
If this sounds familiar, this related guide may help: How can I tell if my spreadsheet is too complex?
What a Day-1 Build does differently
A Day-1 Build isn’t a spreadsheet clean-up.
It takes one important job, tracker, handover, approval list, reporting task or manual way of working and turns it into a working hosted system.
In practice, that means:
- proper forms for adding and updating information
- information held in a clearer shape instead of rows and tabs that are easy to break
- clear lists and views for the people using the system
- simple statuses or stages
- real data loaded where practical
- a live system the team can start using
The aim is simple: replace one important workaround with something clearer, safer and easier to improve, without turning it into a large software project.
You can also read more about how a Day-1 Build works.
When Day-1 Build is a better fit
A Day-1 Build is worth considering when:
- the spreadsheet supports regular work, not just occasional analysis
- several people rely on the information
- handovers, checks or updates keep getting missed
- reporting takes longer than it should
- the spreadsheet has become hard to explain to someone new
- getting a first working version in place is more important than covering every edge case immediately
The strongest examples are jobs the team relies on every week: job trackers, request lists, approval logs, reporting packs, training records, onboarding checklists and customer work queues.
When Day-1 Build is not the right answer
A Day-1 Build is deliberately focused.
It may not be the right answer if:
- the spreadsheet only needs a small tidy-up
- the work happens too rarely to justify a system
- the business has not agreed how the work should happen
- the first version would need too many departments, exceptions or integrations
- the real problem is data quality rather than the system itself
- an off-the-shelf tool already fits the work well
If a clearer spreadsheet, a small process change or an existing tool would solve the problem, that may be the better first step.
The practical test
Ask this:
If the spreadsheet disappeared tomorrow, would the business still know how to run that piece of work?
Yes? Improving the spreadsheet may be enough.
No? The spreadsheet may already be carrying more responsibility than it should.
Next step
If one spreadsheet, tracker or manual way of working has become too important to leave alone, bring it to a Day-1 Build call.
We’ll look at what the work does, where the risk or friction sits, and whether it is suitable for a focused first version.
Prefer to understand the kinds of problems first?