Skip to content
← All ideas

Digital business / Discovery

The best app idea might be hiding in your spreadsheet

A weekly spreadsheet workaround can reveal a repeated problem. Follow it to a first useful result—and decide whether a small tool would help.

A repeated Friday spreadsheet check becomes a focused preparation list. In the illustrative example, eight people need one kit each; five kits in stock leave three to bring.
Original illustration: follow the repeated task to one useful result. Invented quantities explain the calculation; no customer data or measured improvements are shown. View full illustration ↗

The discovery in one minute

Look for the repeated task behind the cells.

A spreadsheet can be a record of how someone gets a job done. Repeated copying, checking or explaining may point to a useful tool. The opportunity is the problem and the result people need—not simply replacing the spreadsheet with an app.

The Friday copying ritual

Imagine you coordinate a community workshop. Each Friday you duplicate last week’s sheet, replace the attendee names, count the kits needed and highlight anything missing. Someone asks which list is current. You send another message explaining the colours. This is an illustrative scenario; we have not interviewed a workshop or measured its results.

The sheet contains a small process: prepare the session, check the supplies and help volunteers know what to bring. A coloured cell is doing the work of a reminder. A copied tab is doing the work of starting the next session. Those little workarounds are clues about the job.

An app idea might begin with one of those clues. ‘Workshop management software’ is broad. ‘Know whether Saturday’s session has enough kits’ is a result you can picture and investigate.

Follow the person and the repeated moment

Ask who does the check, when they do it and what happens if they miss something. The coordinator may need a preparation list; a volunteer may only need the final quantities. They do not necessarily need the same screen or access to everyone’s contact details.

Start by observing the current process with permission. GOV.UK’s user-research guidance recommends learning who the users are, what they are trying to do, how they do it now and where they struggle. It also distinguishes evidence from assumptions supplied by people other than users. [1]

For this example, useful questions would be: how often do quantities change? What has to be checked by hand? Is the confusing part the calculation or finding the latest version? A new interface will not fix an unclear agreement about who updates the list.

Find the first useful result

Suppose the recurring difficulty turns out to be calculating supplies. The smallest tool might accept an attendee count and a kits-per-person rule, then show the total needed and the shortfall against stock. It could produce one readable preparation list. It does not yet need payments, a member directory or a social feed.

That is a hypothesis: a possible explanation to test. Try it with invented numbers first, then ask a willing coordinator to walk through a realistic case. Compare the result with their existing method. Check mistakes, missing information and the effort needed to understand the output.

You could test the layout on paper or improve the spreadsheet itself before writing software. A prototype is a rough version used to learn. The point is to see whether the proposed result helps someone complete the task, rather than collect compliments about the idea. [2]

Some spreadsheets should stay spreadsheets

A sheet is useful when the person doing the work understands it, the structure changes often and a few people can coordinate easily. Moving it into software could make a five-minute adjustment require a developer. The flexibility you remove may be the feature its owner values most.

The stronger case for a tool appears when the same stable task repeatedly causes confusion, several people need a consistent result, or important rules are too easy to overlook. Even then, first consider whether clearer headings, a protected calculation or one agreed source file would solve enough of the problem.

Validate the need and the responsibility

Before building, find out whether the difficulty recurs beyond one person’s particular habits. Check who would keep records current, which exceptions matter, and whether people would use the tool again. If it is intended as a business, also investigate who would pay and what ongoing support they would expect.

GOV.UK’s discovery guidance starts with understanding the problem, users and constraints before committing to a service. Here, that might reveal that the actual bottleneck is late attendance confirmations, which a supply calculator cannot resolve. [3]

Try looking at one sheet you already use. Circle the action you repeat, name the person who needs the result and sketch the smallest improvement. You may find a promising tool. You may find a better spreadsheet. Either outcome teaches you something useful about the work.

Read further

Sources.

References checked on . Source notes explain what each reference supports.

  1. GOV.UK — Learning about users and their needs ↗

    Primary guidance on observing current work, identifying users and treating unsupported suggestions as assumptions.

  2. GOV.UK — Making prototypes ↗

    Exploring and testing designs before a full build. The workshop and possible calculator are illustrative, not test evidence.

  3. GOV.UK — How the discovery phase works ↗

    Understanding the problem, users and constraints before committing to a service. Small-tool suggestions are our editorial interpretation.

Keep exploring

Another idea, made clear.

DiscoveryWhat happens when a book becomes a tool? ↗ExplanationWhy do some digital products succeed? ↗