Your Spreadsheet Problem Was Never a Software Problem

You've already tried everything. The spreadsheet is still open.

By now you've run the playbook.

You bought the better software — the CRM, the ERP, the "all-in-one" platform with the confident sales deck. You've read here why it never replaced the spreadsheet: off-the-shelf tools make your operation bend to the tool, capture the generic 80% of your business, and leave the 20% that's actually you to retreat back into a workbook.

Then you wondered whether AI would finally do it — and found that pointing a model at a broken spreadsheet just automates the chaos, inheriting your errors at machine speed while never seeing the rules you never wrote down.

So there's one option left, and it's the one that feels like the grown-up answer: build our own. Hire developers. Stop renting someone else's opinion of how our business should work and build exactly what we need.

If you've done it, you already know how this ends. The custom build launched. It got used for a while. And then — quietly, the way it always happens — the spreadsheet came back.

This is the last post in a series about why your operations won't leave the spreadsheet. And it's the one that names the thing underneath all three failures.

Why the custom build didn't stick either

Custom software fails for a reason that has nothing to do with the quality of the developers. Give a good team a clear brief and they'll build you a good system. That's exactly the problem.

A custom build is only ever as good as the brief — and the brief is a guess.

Think about how that brief gets written. Someone sits down to specify how the operation works: the statuses, the fields, the rules, the workflow. But the operating knowledge that actually runs the business isn't sitting in anyone's head in specifiable form. It's smeared across a load-bearing spreadsheet, a few key people's instincts, and a hundred small exceptions nobody thinks to mention because they're too obvious to say out loud.

So the brief captures the operation as someone imagines it — tidy, rational, the way it would work if it worked the way you describe it in a meeting. The developers build precisely that. And precisely that turns out to be a subtly wrong model of your own business: the exception isn't handled, the rule that changed in March isn't in there, the "we always check this before that" was never written down. It's the right software for a company that doesn't quite exist.

There's a second failure stacked on the first. Even where the brief was right on the day it was written, a custom build freezes the operation at that moment. Operations drift — regulations change, the pricing model evolves, a new exception becomes routine. The spreadsheet, for all its faults, bends to absorb that drift instantly. The rigid custom app can't, so the team routes around it — back to the spreadsheet — and within a year you're maintaining both.

You didn't build the wrong software. You built software from the wrong starting point.

The thing underneath all three failures

Step back and look at the whole series, because the same shape appears every time.

• Off-the-shelf software fails because it was built for the average business, and yours isn't average.
• AI fails because it can only act on what's already been written down, and the part that matters never was.
• Custom software fails because it's built from a brief, and the brief is a guess about an operation nobody decoded.

Three different tools. One identical root cause: nobody decoded the operation before choosing or building the tool.

That's the sentence the whole month has been circling. Your spreadsheet problem was never a software problem. It was never really about which tool to buy or build. It's that the knowledge of how your business actually runs — the genuine asset — has never been extracted, written down properly, and turned into something a system can execute. Every tool you've tried assumed that work was already done. It never was. It's still sitting in the spreadsheet, which is why the spreadsheet keeps winning.

Once you see it that way, the order of operations flips. The question stops being "what should we buy or build?" and becomes "has anyone actually decoded how this business runs?"

What decoding first actually changes

This is the discipline we work in, and it's why we named it.

Operational Encoding is the practice of researching how an industry actually operates — its regulations, formulas, workflows and unwritten rules — and encoding that operating knowledge into purpose-built systems, before any software gets built. I coined the term — Schalk van der Merwe, at 4What Digital — and the whole methodology lives at 4whatdigital.com/operational-encoding. It runs in three moves, and the order is the entire point:

Decode. Before anyone writes a brief or a line of code, research the operation the way a practitioner lives it — regulations, formulas, workflows, and the unwritten rules that were never in anyone's head in specifiable form. The load-bearing spreadsheet is treated as the primary source it actually is: the most honest documentation the business has ever produced.

Encode. Now build — around what was decoded, not around a guess. The system understands the industry's rules natively, models the exceptions instead of ignoring them, and enforces the thresholds automatically. The operator recognises their own week in it, so they stop routing around it.

Learn. Because the operation was decoded rather than frozen, the system keeps absorbing live operational data — surfacing patterns no spreadsheet ever could, and getting smarter the longer it runs instead of drifting out of date.

Notice that "build custom software" isn't the opposite of this — it's the second move of it. Custom software isn't wrong. It's premature. Decode first, and the build you were always going to do finally sticks, because for the first time it's built on your operation as it really is instead of as someone guessed it to be.

The question to ask before you buy or build anything

Next time someone proposes the fix — a new platform, an AI pilot, a custom build, another rollout — ask one question before the budget conversation starts:

Has anyone actually decoded how this operation runs — the rules, the exceptions, the things only two people know — or are we about to automate a guess?

If the honest answer is "we'll figure that out during implementation," you already know how it ends. It ends the way the last three attempts did: with the spreadsheet still open, quietly holding the 20% of your business that nobody ever wrote down.

The spreadsheet was never the problem. It was the evidence. It's been telling you, this whole time, exactly which part of your operation still needs to be decoded — and it will keep winning until someone does.

FAQ: software, spreadsheets and what to decode first

Why does custom software fail to replace spreadsheets?

Because it gets built from a brief, and the brief is the business's best guess about its own operation. The rules that actually matter — pricing logic, compliance thresholds, exceptions — live in spreadsheets and in people's heads, not in the requirements document. Developers build exactly what was specified, which is precisely the wrong thing, built well. Without decoding the operation first, a custom build is a snapshot of a guess.

What is Operational Encoding?

Operational Encoding is the discipline of researching how an industry actually operates — its regulations, formulas, workflows and unwritten rules — and encoding that operating knowledge into purpose-built systems, before any software gets built. The term was coined by Schalk van der Merwe at 4What Digital. The methodology runs in three moves: decode the existing operation, encode it into a system built for that industry, and let the platform learn from live operational data.

Is building custom software a mistake?

No — building is the right destination. It's just the second move, not the first. Custom software fails when it's the starting point, because the operating model hasn't been decoded yet. Do the research first, encode what you find, and the build sticks. Skip the decode and you've paid to automate a guess.

What's the common reason software rollouts don't stick?

The same one across off-the-shelf tools, AI and custom builds: nobody decoded the operation before choosing or building the tool. Each approach captures the generic 80% of a business and misses the 20% that makes it that specific business — so the spreadsheet quietly keeps that 20%, and it comes back.

Schalk van der Merwe is co-founder of 4What Digital, where he leads Operational Encoding for operations-heavy businesses. Reach him at schalk@4whatmarketing.com or start with what Operational Encoding is.