How to turn a spreadsheet into a web application

Nobody ever sat down and decided that a spreadsheet should run part of the business. It arrived as one person's convenience, it worked, and then it was load bearing.

If that is where you are, the instinct is to replace it with a system. That instinct is usually wrong, and acting on it is how a £2,000 job becomes a £30,000 one.

Here is the way through: what to look at, what to leave alone, and how to describe it so somebody can price it without a meeting.

Do not replace the spreadsheet#

Start here, because it saves the most money.

A spreadsheet that has survived five years is doing dozens of jobs, and most of them it does well. It calculates. It lets somebody look at a hundred rows at once and spot the odd one. It bends on a Tuesday when the business changes its mind. No system you commission will be better at any of that, and every one of those jobs you rebuild is paid for twice: once to build, once to maintain.

What a spreadsheet is genuinely bad at is a short list, and it is the same short list almost every time.

The four things it cannot do#

Two people at once. This is the big one, and it fails quietly. Two copies, two sets of edits, one saved over the other, and nobody notices for a fortnight. The damage is not the lost work, it is that you can no longer trust any figure in the file.

Stop somebody entering nonsense. A date in a quantity column, a customer that does not exist, a discount of 150%. A spreadsheet accepts all of it. By the time a human spots it, the number has been in three reports.

Remember who did what. No history, no audit trail, no answer to "who changed this and when". Fine until the day it matters, and on that day there is nothing to look at.

Act on its own. It cannot email somebody when a figure crosses a line, cannot refuse to proceed when a step is missing, and cannot do anything at 2am.

If the pain you are feeling is not on that list, the answer is probably not software. It might be a better spreadsheet, or one hour of somebody competent fixing the formulas.

Work out which columns actually matter#

Open the file and ask which columns the business would be in trouble without.

In our experience it is three to six out of forty. The rest are working notes, half-finished ideas, a column somebody added in 2019 and a lot of formatting. The small number that matter are the ones that need rules, a history and a single copy. Those become software. Everything else can stay exactly where it is.

This is the step that decides the price of the whole job, and it is the step most often skipped, because it is less satisfying than drawing screens.

What usually gets built#

For most of these jobs it is smaller than people expect:

• A form that will not accept nonsense, replacing the row somebody typed by hand.
• One screen that shows the current state, so nobody has to open the file to find out.
• A record of changes, because it costs almost nothing to add while building and cannot be added retrospectively.
• An export, so the spreadsheet carries on being the place people look at a hundred rows at once.

That last point matters more than it sounds. Keeping the export means nobody has to stop using the thing they know on the day the new screen appears, and adoption stops being a risk.

How to describe it so it can be priced#

Attach the actual file, with real data in it if you can. A developer looking at your real spreadsheet will see in four minutes what you would not have thought to mention in an hour of talking.

Then say, in plain sentences:

What goes wrong now: the specific failure, with how often

Who touches it: how many people, and whether ever at the same time

What must not change: the reports, exports and habits that have to survive

The columns that matter: the three to six, named

What it costs you today: time per week, or the error it caused

That is enough to grade and price most of these without a single question coming back.

What makes it cost more#

Worth knowing so a higher price reads as an explanation rather than a brush off.

The spreadsheet is the only record. If there is no other source for the history in it, that data has to be moved carefully rather than quickly, and moving it is often bigger than building the screen.

The formulas are the business logic. Thirty years of decisions sometimes live in nested formulas nobody can explain. Working out what they do is real work and should be priced as its own small job, separately, before anything is built.

It has to talk to something else. An accounts package, a stock system, a payment provider. Each one is a known quantity, and each one adds work.

Several people disagree about what it does. Not a technical problem, and the most expensive one on the list. It is worth settling before anybody writes code.

The cheapest honest first step#

Not a project. One short piece of paid work that answers three questions: which columns matter, what the formulas actually do, and what the smallest useful thing to build is.

You should get a written answer and a price for the next step, and you should be free to take both elsewhere. If the conclusion is that the spreadsheet is fine and needs an hour of tidying rather than software, that is a legitimate result and you should be told it plainly.

What we do#

There is no minimum here, so "look at my spreadsheet and tell me what is really going on" is ordinary work rather than a favour granted around the edges of a bigger project.

You send the file and describe what goes wrong. It gets graded by size and you get a price in writing before anything starts. Nothing begins until you approve it, and if the number is wrong for you, you walk away owing nothing.

Thirty years of this means the answer is sometimes that you do not need us, or need far less of us than you expected. We will tell you that in writing, because a spreadsheet that works is not a problem to be solved.

The price changes with the size of the job. The standard never does.