Your spreadsheet already runs the business. I turn it into software.
Somewhere in your company there is one spreadsheet that actually runs things. It prices the jobs, schedules the crews, or does the one calculation that only you really understand. People have probably been telling you for years to replace it with "real software." And you probably haven't, because you've seen how that goes: someone buys or builds the replacement, the team quietly hates it, and a year later everyone is back in Excel.
I build the version of that story that works. I take your workbook and rebuild it as a clean web app, then verify the new software against your spreadsheet's own answers before you ever rely on it. You can pay a fixed fee and own it outright. Or, if your spreadsheet solves a problem your whole industry has, we can build it together and split the revenue when your peers buy it.
The part everyone gets backwards.
Most developers treat your spreadsheet as the embarrassing thing they're replacing. I think that's exactly backwards. That workbook is a validated prototype. Every weird rule in it exists because a real job went sideways once. It has been tested against actual customers and actual mistakes, usually for years. That is the most expensive part of any software project, and you already own it.
The market for turning it into software is honestly a mess. There are $100 gig-site conversions, $3,000 freelancer rebuilds, and $30,000 agency MVPs, and they typically share the same failure mode: they rebuild your logic from scratch, get most of it right, and you find out what they missed in front of a customer. The no-code tools have the same problem from the other direction - they're good at lists and lookups, and they quietly fall over on deep calculation logic.
So I run these builds under a different rule. Your spreadsheet stops being the thing we're replacing and becomes the thing we test against. If the app and the workbook ever disagree, the app is wrong.
The parity test.
Here's the promise every build ships under: before your team switches over, the new software has to reproduce your workbook's own answers. Not "close," not "within rounding" - the same numbers your spreadsheet gives today.
The mechanics are simple to describe. Your workbook already contains years of its own test data: the real calculations it has produced, sitting right there in the file. I extract every formula, rebuild the logic as software, then run those historical calculations through the new build and compare each output against what your spreadsheet says. Every comparison is a check, and the software ships only when it passes all of them. Even where the workbook's behavior looks odd. Plenty of workbooks round in strange places on purpose, and the software honors that instead of quietly "improving" it.
You see the results in writing. Every build hands over a parity report listing every check and its result, plus the test suite itself, which stays with the software. Any future change reruns every check automatically, so the logic can't quietly drift a year from now when somebody adds a feature.
Two honest warnings from doing this work. First, parity testing tends to surface real bugs in the original spreadsheet - a cell silently reading the wrong range, a total that truncates. Almost every serious workbook I've opened in the last decade has a few. When that happens, you decide, case by case, whether the software keeps the old behavior or fixes it. That's your call to make, not mine, but you can't make it if nobody ever finds them. Second, perfect math on its own doesn't make good software. So before anyone relies on the build, we re-enter real jobs end to end in working sessions, because interface problems never show up in the numbers.
What you end up with is not your spreadsheet wearing a costume. It's software: guided inputs instead of a wall of cells, warnings when something isn't ready, and outputs your business actually sends, produced by anyone on the team instead of the one person who knows how the whole thing works.
Save both of us the wrong call.
This is probably a fit
- One spreadsheet already runs a core process: quoting, pricing, scheduling, capacity, compliance. It touches money every week.
- The logic is stable. You trust the numbers. You're not still figuring out the model.
- You or someone on your team built it and understands it. The knowledge inside it is the point.
- Your industry is specific. Freight, cold storage, crop spraying, equipment hire - the weirder the niche, the better this works.
- For a partnership: other companies in your niche have the same problem, you know them by name, and you're willing to sell to them.
This is probably not
- There's no spreadsheet yet. An idea for an app is a different kind of project, and honestly probably not mine.
- The real job is cleaning messy data, fixing formulas, or general Excel support.
- You're shopping for the cheapest possible build. I'm not it, and the $100 conversions genuinely exist.
- You need procurement, security review, and a 9-month vendor process. All real needs, wrong offer.
- You're hoping I'll do the selling. I build the product and the sales materials. The relationships and the phone calls are yours.
How the deal works.
There are two ways in.
A fixed build
You pay a fee, I rebuild the workbook as software and prove it matches, then hand it over. You own it outright. Builds start at $20,000 and typically take a few weeks once I have the workbook, not months. If all you want is your own tool, this is the clean option.
A partnership
If your spreadsheet solves a problem every company in your niche has, we build it once and sell it to your industry. You bring the domain knowledge and the relationships. I build and run the software. We split the revenue. The build fee is $8,000 instead of the fixed price, and my share lands somewhere between 10% and 20% of revenue depending on who carries hosting and support.
A few rules I hold on partnerships, learned mostly from watching other people's version of this deal go wrong:
- There is always some cash. If neither of us has real money in, neither of us treats it like a business.
- We split revenue, not "profit." Profit is an accounting argument waiting to happen. Revenue is a number we both read off the same shared sales dashboard, every transaction visible to both of us.
- The awkward stuff gets decided up front, in writing: who owns what, what happens if you stop selling, what happens to you if I get hit by a bus (you get the code and the tests), and how either of us buys the other out.
- I take on very few of these. A partnership puts my time at risk instead of your money, so I'm picky in exactly the way you'd want a business partner to be picky.
Asked before you ask.
How do I know the software will actually match my spreadsheet?
Because matching is the condition for shipping, not a goal. Your workbook's own historical calculations become the test suite, and the new software has to reproduce every one of them. You get the parity report showing exactly what was checked, and if a single check fails, the build isn't done.
Who owns the software?
On a fixed build: you, outright, including the code and the test suite. On a partnership: the agreement spells it out before I write a line, including a buyout price for each side. Your spreadsheet, your rates, and your methods stay yours in every version of this.
What happens when it breaks?
Software breaks in ways spreadsheets don't, usually at a bad time. Every build ships with the parity test suite, so any change gets automatically re-checked against your workbook's own answers, and hosting and maintenance terms are part of the deal rather than an afterthought. And if I vanish, you have the code and the tests. You're never hostage to me.
Why would you take a share instead of just charging more?
Because a fee caps my upside at the fee, and I'd rather own a slice of a product your industry actually buys. The honest downside for you: if it takes off, the share costs you more than a fee would have. The honest downside for me: most of these won't take off, which is exactly why every partnership still starts with a real build fee.
What stops you from taking my domain knowledge and selling it yourself?
The agreement, first of all. But also the practical truth: I can't sell freight audits, equipment hire, or crop-spray scheduling to anyone. You know the industry and the people in it. I know how to build software that doesn't lose your logic. The split exists because neither of us is any good at the other's half.
Couldn't I just use a no-code tool?
Maybe, and if your spreadsheet is a few tables and lookups, you probably should - it'll cost you $50 a month instead of five figures, and I'd genuinely rather you do that than overpay me. Those tools struggle when the value is deep calculation logic: nested conditions, pricing engines, the giant multi-sheet monsters. If that's what you have, the conversion is where they break, and that's my lane.
My spreadsheet contains our rates and margins. How is that protected?
Your model never becomes public. Builds are hosted privately and access-controlled, and I'll tell you to strip or anonymize anything sensitive before you ever send a file. I work with pricing models regularly; treating them as confidential is the default, not a special request.
Do we have to get on calls?
Some, yes. My smaller design services are deliberately async, but this is a build (or a business deal), and pretending it fits in a form would be dishonest. Expect a scoping call and a working session or two. Not a weekly meeting cadence.
What does it cost, exactly?
Fixed builds from $20,000, scoped after I see the workbook. Partnerships: an $8,000 build fee plus a 10-20% share of revenue. If your budget is a few thousand dollars total, the freelancer route is a better fit, and the fixed-price conversion shops do exist.
Tell me about your spreadsheet.
No file upload and no ten-question homework assignment. I need the short version: what the spreadsheet does, and what happens in your business the week it breaks. If a partnership is on your mind, include the first three companies you'd sell it to and how you know them. How easily you can answer that question tells us both something.
If it fits, I'll tell you exactly what to send next. If it doesn't, I'll tell you that too. Worst case, you find out your spreadsheet should stay a spreadsheet - which is free, and more useful than a lot of paid advice.
Prefer email? cottrell@hey.com works too.