A few years back, I talked to the founder of a logistics software company that had just closed a Series A. The product helped small freight brokers manage their loads. By the time they raised, they had real revenue, real customers, and a real operations team. They also had, tucked behind their polished web app, a Google Sheet that their COO updated every morning with the previous day’s numbers.
The investors didn’t know about the sheet. The customers didn’t know. The sheet tracked things the product couldn’t yet report on: which customer segments were churning, which sales rep was closing deals that actually stuck, what the margin looked like on their smallest accounts. The founder called it “the real dashboard.” The product’s analytics tab, she told me, was mostly there to look good in demos.
That’s not a confession of failure. That’s a masterclass in prioritization.
The Setup
Spreadsheets have a reputation problem in startup circles. Admitting you run something critical on a spreadsheet feels like admitting you haven’t grown up yet. There’s a whole cottage industry of tooling designed to replace spreadsheets, and a whole culture of VCs who ask, as part of due diligence, what your data infrastructure looks like.
But walk into the back office of almost any company that went from zero to meaningful revenue, and you’ll find at least one spreadsheet doing work it was never officially supposed to do. Often several. Sometimes for longer than the company would ever publicly admit.
The logistics company I mentioned isn’t an outlier. It’s the rule with a different name every time.
What Actually Happened
The founder, call her Sarah, built the core product with two engineers over about eighteen months. The product handled load tracking, carrier communication, and invoicing. It was good. Customers paid for it.
But the product was built for customers, not for Sarah. It didn’t tell her what she needed to know to run the company. So she built what she needed in Sheets.
Column A: customer name. Column B: contract value. Columns C through N: twelve months of actual revenue collected, month by month, so she could see contraction and expansion visually without needing a BI tool. A second tab for her sales pipeline, manually updated after every rep call, because the CRM they used (a mid-tier tool chosen partly for its price) didn’t export in a format that was useful without an hour of cleanup.
The sheet grew. At one point it had seven tabs, a dozen conditional formatting rules, and a VLOOKUP chain that her COO described, affectionately, as “genuinely alarming.” It crashed browsers occasionally. It had one known data error that they’d stopped trying to fix because fixing it would require rebuilding three tabs.
They kept it anyway. Because it worked.
When they started the Series A process, an advisor told Sarah to clean up the data infrastructure before investor meetings. They brought in a contractor to stand up a proper pipeline: a data warehouse, a BI layer, the works. The contractor delivered it about six weeks into the fundraise. Sarah used it to prepare a few slides, found it took three times longer to answer her questions than the sheet did, and went back to the sheet for the rest of the process.
The company raised at a valuation that reflected their actual business performance. The sheet was never mentioned in the pitch deck.
Why It Matters
The standard startup advice is to automate and systematize early. Build for scale. Don’t let operational debt accumulate. And there’s truth in that, especially on the engineering side, where the cost of cutting corners compounds quickly.
But there’s a version of that advice that gets weaponized against founders who are making smart tradeoffs. The implicit pressure to look like a “real company” causes founders to invest in infrastructure before they know what questions that infrastructure needs to answer. You end up with a beautifully architected data warehouse that nobody queries, because nobody is sure what they’re actually trying to learn yet.
Sarah’s sheet worked because it was built around the specific questions she needed answered. It was ugly and brittle and had a broken VLOOKUP. It was also perfectly calibrated to her company at that stage. The contractor’s pipeline was cleaner and more scalable. It was also built for a generic version of her company that didn’t quite exist yet.
This is the real lesson. The problem with a spreadsheet isn’t the spreadsheet. The problem is when founders mistake the spreadsheet for a permanent solution instead of an honest temporary one, and then fail to replace it at the right moment.
Sarah knew what the sheet was. She wasn’t confused about its limitations. She used it because replacing it was, at that stage, a worse use of resources than the problem it would have solved. After the Series A closed, she brought in a data engineer full-time and gave them three months to make the sheet obsolete. By the time they hit Series B, the sheet was gone.
What We Can Learn
The mythology of the modern startup involves clean systems from day one. It’s nonsense, and founders who believe it waste real money trying to live up to it.
The practical lessons here are specific:
Know what your spreadsheet actually is. If it’s a temporary stand-in while you figure out what questions matter, that’s fine. If it’s a permanent avoidance mechanism because building the real thing would force uncomfortable conversations, that’s a problem. The founders who get into trouble aren’t the ones running on spreadsheets. They’re the ones who’ve convinced themselves the spreadsheet is fine indefinitely because replacing it would require admitting the product doesn’t do what they told customers it does.
The tool you use to run the company is different from the tool you sell. Sarah’s product was genuinely good. Her internal operations were held together with Sheets and discipline. These two things coexisted without contradiction. The instinct to conflate them, to think your internal tools need to reflect the same maturity as your product, is a trap that mostly serves the vendors selling internal tooling.
Replace the spreadsheet when the cost of its failure exceeds the cost of building the replacement. Not before. Sarah’s sheet had a broken VLOOKUP and crashed browsers. The cost of those failures was annoying but contained. When the company’s complexity grew past the point where one person could maintain the sheet accurately, the calculus changed. That’s when she invested.
Investors are not actually checking your data infrastructure. They’re checking whether you understand your business. A founder who can answer hard questions about unit economics from a spreadsheet is in a better position than a founder with a beautiful Looker dashboard who fumbles when asked why net revenue retention dropped two points last quarter. The tool is not the point. The understanding is the point.
Every company that has ever scaled has a graveyard of intermediate solutions that were embarrassing at the time and indispensable in practice. The spreadsheet is almost always in that graveyard. The founders who thrive are the ones who aren’t ashamed of it being there, and who knew exactly when to replace it.
