Last year I built a custom app for a jewellery retailer who was running their entire business from a Google Sheets workbook. 47 tabs. Vlookups nested inside vlookups. A tab called "DO NOT DELETE" that nobody understood but everyone was afraid to touch.
Here's what happened, what I learned, and what I'd tell any developer considering this kind of project.
The Spreadsheet Was Load-Bearing
The owner had been adding tabs for six years. What started as an inventory list had grown into:
- Customer records (with purchase history across 3 tabs)
- Repair job tracking (with a colour-coding system only she understood)
- Commission calculations for 4 staff members
- Valuation certificates (linked to a separate folder of PDFs)
- Monthly reporting (copy-paste from other tabs into a "Reports" tab)
It worked. Barely. But it worked. And that's the dangerous part — it worked just well enough that nobody had the urgency to replace it, but poorly enough that everyone lost hours every week to errors, slowness, and "who changed this cell?"
Why They Finally Called Me
Two things broke at once:
A new employee accidentally deleted a formula that cascaded through the commission tab. Nobody noticed for three weeks. Three weeks of wrong pay calculations.
Google Sheets started timing out because the workbook was too large. They couldn't open the repair tracker during busy periods — exactly when they needed it most.
The breaking point wasn't a feature request. It was a failure.
What I Actually Built
Not a replica of the spreadsheet. That's the mistake most developers would make — faithfully reproducing every tab and formula in a web app. That just gives you a slower, more expensive spreadsheet.
Instead, I sat with the owner for two days and asked one question repeatedly: "What decision does this data help you make?"
Turns out, about 60% of the spreadsheet was legacy. Data captured because it seemed important at the time but never actually used. We stripped it out.
The app I built had:
- A customer CRM with purchase history and communication notes (replacing 3 tabs)
- A repair tracker with status workflow, photos, and automated customer notifications (replacing the colour-coded tab)
- A commission engine that calculated automatically and couldn't be accidentally broken (replacing the formula nightmare)
- Valuation management with PDF generation and digital delivery (replacing the folder of files)
Built with TypeScript, React, Node.js, PostgreSQL, and Prisma. Deployed on Railway. Total build time: 5 weeks.
What I Learned
1. The real requirements aren't in the spreadsheet
They're in the workarounds. The colour-coding system. The sticky notes on the monitor. The "always do X before Y" verbal instructions passed between staff. Interview the people, not the cells.
2. Business owners don't want features — they want fewer mistakes
The owner didn't ask for a dashboard or charts or a mobile app. She asked for "something that won't let someone accidentally delete three weeks of pay data." Start with the pain, not the polish.
3. Data migration is the hardest part
Six years of inconsistent data entry. Names spelled differently. Dates in three formats. Empty fields where there should be values. I spent more time cleaning and migrating data than building the app.
4. Don't build what they have — build what they need
If I'd replicated every tab, I'd have built a 12-screen app. Instead I built 4 screens that covered 95% of daily operations. Less code, fewer bugs, faster delivery, easier to learn.
5. Training is product work
The best feature in the app is the onboarding tour. Three minutes, covers everything. If a new staff member can't use it without training, the UX needs work — not a manual.
The Numbers
- Build cost: Mid four figures (fixed price, no hourly billing)
- Monthly hosting: Under EUR 20
- Time saved: Estimated 8-10 hours per week across the team
- Data errors: Zero accidental deletions since launch
- ROI payback: Under 4 months
Should You Build Custom Software for Spreadsheet Replacement?
Only if these are true:
- Multiple people use the spreadsheet daily
- You've had at least one serious data error
- The workarounds are becoming the process
- The spreadsheet is slowing down or timing out
- You can articulate the 3-5 decisions the data actually supports
If all five are true, a custom app probably pays for itself in months.
If only 1-2 are true, you probably need a better spreadsheet, not custom software.
I'm John, a developer in Cork, Ireland. I build custom software and Shopify apps for businesses that are too specific for off-the-shelf tools. If your spreadsheet is holding your business together with vlookups and prayers, I'd like to hear about it.
Top comments (0)