Skip to content
Breitloh

The spreadsheet that became a system

Most businesses have one: a workbook with twelve tabs, three macros, and one person who understands it. It works, until two people need it at once. Replacing it is not a big project if the rules are already written down in there, and they usually are.

Book a callWebsite design and build

Ten of my fifteen years were spent building this kind of system on enterprise platforms, mostly ServiceNow, for FTSE 100 companies, central government departments, and local authorities: requirements workshops, agile delivery, test cycles, and demos to people who did not ask for the meeting.

Records, rules, and the people allowed to act on them, in one system rather than a spreadsheet

Where it usually hurts

One person is the system
The process lives in somebody's head and in a file on their desktop. Holidays are difficult, leaving is worse, and nobody can say for certain what the rules are without asking them.
Off the shelf nearly fits
There is a product that does eighty percent, and the missing twenty is the part your business actually competes on. So it gets bought, worked around, exported to a spreadsheet, and re entered by hand.
It is nobody's job to fix
Too small for an IT project, too big to keep ignoring. It sits in the gap for years, quietly costing a few hours a week and one serious mistake a year.

What the job covers

  • The rules written down first, including the exceptions people apply without noticing they do
  • A working thing early, on a real address, so you are reacting to something rather than approving a document
  • Roles and permissions, so the right people can do the right things and everything is recorded
  • The data in your own accounts, exportable, in a format another developer could pick up
  • Handover with the code, the accounts, and a walkthrough, so nobody is locked in, including to me

What it has to talk to

Whatever holds the truth today
The accounting system, the CRM, or the spreadsheet itself. Reading from what already exists beats a migration nobody has time for, and it means nothing has to be right on day one.
How people sign in
Microsoft or Google accounts where you have them, so there is no new password and access ends when somebody leaves. That single decision removes most of the security conversation.
The website, if it needs to reach it
Where customers should see part of it, that part gets exposed deliberately rather than by copying data into a second place, which is how the two versions start disagreeing.

A worked approach, not a client

How I would replace a spreadsheet nobody can retire

  1. 01

    Read the spreadsheet properly

    The formulas are the specification, and the exceptions are in the comments and the coloured cells. Two hours with the person who maintains it is worth a month of requirements workshops.

  2. 02

    Build the smallest useful version

    One job, done properly, in front of real users inside a few weeks. Everything else waits, because the second version of a thing people have used is far better than the first version of a thing they described.

  3. 03

    Move the work over, then the data

    People use it alongside the spreadsheet until the spreadsheet is redundant, rather than switching on a Monday and hoping. The old file gets archived, not deleted.

Questions I get asked about this

The ones that come up on almost every first call. If yours is not here, ask it and you will get a straight answer.

How is this different from a website?

A website tells people things. An application does work: it holds records, applies rules, and knows who is allowed to do what. The technology overlaps, the discipline does not, and pretending otherwise is how projects like this go wrong.

Should we buy something off the shelf instead?

If something fits, buy it, and I will say so on the call rather than quote for building it. Building is right when the awkward part is the part that matters to you, or when the per user pricing of the product makes it painful at the size you are heading for.

What does a custom application cost?

More than a website and less than people expect, because the first useful version is deliberately small. It is quoted as a fixed price for a defined first version, then further work is quoted the same way. How the money works applies here as it does to everything else.

Who owns the code?

You do, from the first commit, in your own repository and your own accounts. That is the whole point of building rather than renting. Another developer could pick it up, and if you ever want that, it is a handover rather than an extraction.

Can it handle logins and permissions safely?

Yes, and where you already have Microsoft or Google accounts, people sign in with those, so there is no new password to manage and access ends the day somebody leaves. Access is checked on every request rather than assumed, which is the same principle behind a client portal.

What about our data and GDPR?

The data stays in your accounts, in a region you choose, with a record of who did what. Access rights and deletion requests are easier to answer when there is one system holding the truth rather than four spreadsheets and an email archive.

Do you use AI in these?

Where it earns its place and not as a headline. Reading a document so somebody does not have to retype it is useful. A chatbot in front of a process nobody has fixed is not, and I would rather sort the process out first.

What if it needs to keep growing?

That is the normal case, so it is built to be added to and priced in defined pieces rather than as an open ended arrangement. If you would rather your own team took it on later, the handover is real, and nothing about it is designed to make leaving hard.

Related

Tell me what you have now

Half an hour on a call, and a straight answer about whether this is the right job and whether I am the right person for it.

Book a callhello@breitloh.com