The Software Is Already in Your Business. You're Just Running It in Excel.

Most service firms don't need new software. They need the one workflow they're already drowning in turned into a product they own — and the spreadsheet they built to cope is the blueprint.

The short version

• The messiest spreadsheet in your business isn't a problem to migrate. It's a specification for the product hiding inside your operation, written in your own hand.
• "Shadow" spreadsheets exist precisely where your real, repeatable, valuable work lives — which is exactly where a product belongs.
• The cheapest way to build that product is rarely from scratch. It's to repurpose the back-office system you already run on, the way we turned Kontor's broker platform into the Hey Offices marketplace without rebuilding the engine.
• This isn't a tooling decision. It's a positioning decision: the same workflow can stay an internal cost centre, or become a customer-facing product that lifts what your business is worth.
• You don't find this product by brainstorming. You find it by reading the spreadsheet your team won't admit they depend on.

The spreadsheet is the spec

There is a spreadsheet somewhere in your business that runs more of it than your actual software does. It has a name like "Tracker v4 FINAL," two or three people have memorised its logic, and it holds information your official systems don't. That isn't a sign of disorganisation. It's the most honest document in the company.

Most commentary treats these spreadsheets as a risk to be eliminated. The conventional take is well documented — spreadsheets get stretched into roles they were never designed for, acting as databases, workflow engines and lightweight CRMs until errors and opacity creep in. That's all true. But "get rid of the spreadsheet" misses what the spreadsheet is telling you.

A shadow spreadsheet is a diagnostic. As one analysis of shadow workflows put it, every spreadsheet your team built alongside the official system is a map of the gaps in that system. I'd push it further: it's not just a map of the gaps — it's a map of the product. People only build and maintain a manual system around work that is repeatable, valuable and painful enough to be worth the effort. That is the exact intersection where software products live.

So before you ask "what should we build," ask a better question: what is the spreadsheet already doing that the business can't run without? Most people who decide to turn a spreadsheet into an app stop at a like-for-like copy — the same grid, now in a browser. That's the small version. The bigger move is to ask what product that spreadsheet is the rough draft of.

Why does the most valuable software in a service business stay hidden?

Because it doesn't look like software. It looks like work. The matching, the chasing, the version-controlling, the "let me just check the sheet" — it's so woven into how the business runs that nobody sees it as a product. They see it as the job.

Off-the-shelf tools don't surface it either. They're built to serve everyone, so they rarely match any single company's process, and teams paper over the mismatch with workarounds — more spreadsheets, more manual handoffs, more duplicated entry. The workaround becomes permanent. The genuinely valuable thing — your specific way of doing the work — stays trapped in cells and muscle memory.

This is the founder bottleneck in software form. The business depends on a process that depends on a person who depends on a spreadsheet. Nothing about that scales, and nothing about it is sellable. We've written before about why the same problem exhausting you is making your business worthless — the hidden workflow is usually where both problems originate.

What it looked like with RiskPod

Mark ran compliance contracting. The operation lived in a spreadsheet: contractors tracked across multiple clients, no shared visibility on who'd been submitted where, constant risk of two team members pitching the same contractor to the same client. The spreadsheet was the business. It was also the bottleneck.

He went to agencies first. The quotes came back at £130K+ with six-month timelines — 47-page proposals full of phases and milestones that looked safe and felt like he'd need to raise money just to find out if the idea worked.

I sent him a working prototype in five days. Not a proposal — a product. The same compliance contractor marketplace, with AI-powered onboarding, document verification and intelligent matching, built for £40K in 30 days. It got 550 signups in the first 48 hours and now runs on a £10K/month retainer. The spreadsheet didn't need migrating. It needed recognising as the product it had always been.

The cheapest product to build is the one you already run on

Here's the part most people miss. When the workflow becomes a product, you usually don't start from a blank page. The most valuable product a service business can build is often already sitting inside the tools it uses to run itself — and that includes the proper software you've already paid to build, not just the spreadsheets.

Kontor is one of the UK's leading office brokers. They'd built a back-office platform that made their brokers over 4× more efficient — years of inventory, broker logic and operational know-how, all already encoded in software. Then success created a problem: a flood of small 1–10 person companies were eating broker time the economics couldn't justify.

The obvious move was to build a new customer-facing product from scratch — months of work, six figures, rebuilding logic they already owned. We didn't do that. We rebranded and re-pointed the existing back-office to face customers, extended it so leads flowed automatically to providers, and wrapped it in a landing page that made the value land. That became Hey Offices: 1,800+ offices online, a 4.9 Google rating, small clients self-serving while brokers focused on the clients that fit the model. A whole new B2C product, and not a line of the engine rebuilt — because the engine was already there.

That instinct is the whole game: find the product latent in the workflow, then build it the cheapest way that ships — which is usually by repurposing what already exists.

Internal cost or customer product? That's a positioning call, not a tech call

Once you can see the workflow as a product, you have a decision that has nothing to do with code. The same underlying system can be three different businesses: something you use internally to run leaner, something you sell direct to your clients, or something you license to your whole industry.

RiskPod and Hey Offices both took the workflow customer-facing — and that's where the value compounds. A service business that runs on owner-dependent processes sells, if it sells at all, for a low multiple of revenue. The same business with a product layer — recurring revenue, defensible methodology, something that works without the founder in the room — is a fundamentally different asset. The workflow you've been treating as overhead is the thing that could change what your business is worth.

The point is that this is a choice you get to make deliberately, instead of leaving the most valuable asset in your business sitting idle in a spreadsheet because no one recognised it.

How do you actually find the product hiding in your business?

Don't brainstorm. Brainstorming invents problems you don't have. Instead, read what's already there. Three questions surface it faster than any strategy session:

First, where do people look when they need the real status? Not the official system — the place they actually trust. That's your shadow workflow, and it's almost always a spreadsheet.

Second, what would break if a specific person were out for two weeks? The answer names both your bottleneck and your most productisable process at once.

Third, what's the question clients or staff ask you over and over? Repetition is the market doing your validation for free. The thing people keep needing is the thing worth building.

Then resist the urge to scope big. The product isn't "digitise the whole business." It's the single, painful, repeated workflow the spreadsheet already proves matters. We go deep on the live version of this diagnostic in how I actually find the product inside a service business — it's the real decisions made in real time, not the tidy marketing version.

Frequently asked questions

Isn't a spreadsheet good enough if it already works?

A spreadsheet works right up until it doesn't — and the failure modes are quiet. The risk isn't that it stops calculating; it's that it ties a critical process to one person's memory, can't be sold as part of the business, and silently caps how much you can grow. If the spreadsheet runs something genuinely valuable, that's the argument for turning it into a product, not against it.

How is this different from just buying workflow software?

Off-the-shelf workflow tools make you bend your process to fit their structure. The whole reason the spreadsheet exists is that no generic tool matched how you actually work. Building from your own workflow keeps the thing that makes you valuable — your specific method — instead of flattening it into someone else's template.

Do I have to build from scratch?

Usually not, and that's the good news. The cheapest, fastest builds repurpose something you already have — an existing back-office, a database, a tool you already run on. With Hey Offices we shipped a customer-facing marketplace without rebuilding the underlying engine. Starting from what exists is almost always faster and cheaper than a blank page.

What does it cost to turn a workflow into real software?

With AI-accelerated development, a focused product built from one clear workflow typically lands in the £15K–£45K range rather than the £100K+ agencies often quote. That makes custom software for a small business genuinely affordable for the first time. The bigger the scope, the more it costs — which is exactly why starting from the single workflow the spreadsheet already proves matters keeps it affordable.

Is turning an Excel spreadsheet into a software application the same as productising it?

No — and the difference is the whole point. Turning an Excel spreadsheet into a software application usually means rebuilding the same grid as an excel-to-web-app: same columns, same logic, now with logins. That fixes the fragility but captures none of the upside. Productising means asking what customer-facing product the spreadsheet is a draft of — a marketplace, a portal, a self-serve tool — and building that instead. RiskPod and Hey Offices are productised-service examples: the spreadsheet logic became a product other people pay to use, not just a tidier internal tool.

How do I know which workflow is worth productising?

The one your team already built a manual system around. Effort is the signal: people don't maintain spreadsheets for trivial work. If a process is repeated, painful and valuable enough that someone built and maintains a tracker for it, that's your candidate — the validation has already happened.

---

Related reading

• [How I Actually Find the Product Inside a Service Business](https://hellocrossman.com/resources/blog/how-to-find-product-inside-service-business)
• [The 15 Types of Software Products Hiding Inside Service Businesses](https://hellocrossman.com/resources/blog/software-products-service-businesses)
• [From Spreadsheet to Platform: The Anatomy of a Service Business Software Build](https://hellocrossman.com/resources/blog/spreadsheet-to-platform-service-business-software-build)
• [Use It, Sell It, License It: Three Revenue Models for Service Business Software](https://hellocrossman.com/resources/blog/use-it-sell-it-license-it-service-business-software-revenue-models)
• [The Burnout-to-Exit Pipeline: Why the Same Problem Exhausting You Is Making Your Business Worthless](https://hellocrossman.com/resources/blog/burnout-exit-pipeline-service-business)

---

Tom Wild builds production-ready software at Hello Crossman. 18 years in product development, including VP of Product Design at Habito. 100+ products shipped. Book a free discovery call to find the product hiding in your business →