Your spreadsheet is already software. Treat it like it.

Tuesday, the tab called FINAL v3

It's a little after nine. The operations lead has the workbook open on one monitor and the order system on the other. The workbook has fourteen tabs. The one that matters is called FINAL v3, and it has a column that turns orange when something is wrong, a column that turns green when Dana says it's fine, and a hidden tab full of formulas that nobody has touched since the person who wrote them left.

Three people edit it during the day. Someone in finance copies two columns out of it every Monday. The warehouse prints part of it. When a customer calls, whoever picks up searches it with Ctrl+F before they search anything else.

Then someone sorts one column without selecting the others, and for about forty minutes every row belongs to the wrong customer. Nobody notices until Dana gets back from lunch.

If that sounds familiar, the problem isn't that your team is disorganized. The spreadsheet is doing its job. It just quietly became the system your business runs on, and nobody ever got to design it.

It isn't a bad tool. It's a system nobody designed

Spreadsheets win for good reasons. They're flexible, everyone already knows how to use them, and you can change the process on a Tuesday afternoon without asking anyone. Plenty of businesses should stay in one longer than software vendors would like.

But at some point the workbook stops being a place where someone thinks and starts being a place where several people depend. You can usually tell when it happened:

• More than one person edits it, and they've worked out an unspoken rule about who touches which column.
• People make decisions straight from it: what ships, who gets called, what gets paid.
• Formulas encode rules that nobody could recite without opening the cell.
• Other systems get fed by copy and paste from it.
• There's one person who, if they were out for two weeks, would leave everyone guessing.

Any one of those is fine. Three or four together means you're running software with no permissions, no history, and no way to tell what changed or who changed it. That's the moment to stop asking "should we get rid of the spreadsheet?" and start asking "what has the spreadsheet been doing for us?"

Read the spreadsheet like a spec

Here's the part people skip. Before anyone sketches a screen, sit down with the person who knows the workbook best and read it together, column by column. You're not auditing them. You're translating.

A column is a field. If it has a dropdown, it's a field with allowed values. If people type whatever they like, ask what they're trying to say, because there's usually a short list hiding in there.

A color is a state. Orange means "something is wrong," but wrong how? Waiting on the supplier? Waiting on the customer? Waiting on Dana? Every color in that spreadsheet is a status somebody decided not to name. Name them.

A comment is an exception. "Call before shipping, fragile frame" is a rule that applies to some orders and lives in a note on one cell. That's exactly the kind of knowledge that disappears in a migration.

A formula is a business rule. The hidden tab with the lookups is often the most valuable thing in the file. Write each formula out in plain words: "If the destination is outside the region and the item is over this size, use the freight rate." Then check with the people who use it that the words are right. Sometimes they're surprised.

A copy called FINAL v3 is history. People keep old versions because they need to know what something looked like last week. That's a requirement too.

When you're done, you'll have a list of fields, states, rules, and exceptions written in your team's own language. That list is most of the spec for whatever comes next, and you didn't need a workshop to get it.

The route sheets that became an API

We've seen how much a spreadsheet can carry. On Paddle8, the online auction house, the excitement was the live bidding. But once someone won a piece, getting the artwork to them depended on knowledge held in spreadsheets of shipping routes. Part of our work was turning those spreadsheets into a shipping API, so the platform itself could use what the logistics people already knew.

The lesson we took from it is not "spreadsheets bad." The sheets held real expertise. The problem was that the expertise couldn't reach the places that needed it: the platform, the buyer, the next person on the team. Moving it into software kept the knowledge and gave it somewhere to live that other parts of the business could ask.

That's the bar for any spreadsheet replacement. If the new system loses what the old file knew, people will rebuild the old file within a month, usually in a tab called real one.

Don't migrate the whole workbook

Once the spec is written, the temptation is to replace everything at once. Resist it. Most of the workbook is fine where it is. People use spreadsheets to explore, to model, to try something before it's a process. Leave them that.

Move the part that several people depend on. Usually that's one tab, the one people fight over. Give it a real record with the fields and states you named, an owner for each field, a history of who changed what, and a screen or two that fits how people already work. Keep an export so anyone who still wants to pivot the data in a spreadsheet can. You're not taking their tool away. You're taking away the risk that one bad sort reassigns every order.

Then watch. When nobody has opened that tab in a few weeks, archive it. If people keep going back, ask what they're looking for. It's usually a field or a view you missed, and adding it is cheap.

Bring us the workbook

If your team has a spreadsheet like this, it's one of the most useful things you could show us. We'd rather start from the file people actually use than from a requirements document written about it. Open it, show us the tab that matters, and tell us what the colors mean.

A lot of our web application projects start exactly there: a real workflow, the people who run it, and the knowledge they've already written down in cells. When the work is mostly about moving information between systems rather than giving people a new screen, it may be business process automation instead. Either way, the first step is the same. Tell us about the spreadsheet, and we'll read it with you.