Back to blog
Business

Webapp vs spreadsheet: when it makes sense to invest in a web system

By Flávio Emanuel · · 8 min read

The spreadsheet that became a system

Every company starts the same way. One spreadsheet for tracking orders, another for customer records, a third for finances. It works. Until it doesn’t.

The problem isn’t the spreadsheet. Google Sheets is a good tool. The problem is when it becomes the backbone of a process that’s already outgrown what it can handle. And the transition from “spreadsheet that helps” to “spreadsheet that gets in the way” is gradual. You don’t notice until you’re spending more time feeding the spreadsheet than doing the actual work.

My 15-year-old sister was tracking her jewelry orders in a notebook and on WhatsApp. I asked how sales were going and she couldn’t answer. She didn’t know how many open orders she had, who had paid, how much she had to collect. I built a webapp in 4 hours and that solved it.

For a company making $10k/month running on 5 spreadsheets, the logic is the same. The process grew, the tool didn’t keep up. The difference is the company is losing real money every day it doesn’t migrate.

5 signs the spreadsheet can’t keep up anymore

1. More than one person edits at the same time

Google Sheets allows simultaneous editing. But it doesn’t prevent conflicts. Two people edit the same cell, one overwrites the other. A formula referencing another tab breaks because someone deleted a row. A filter one person applies confuses the other.

In a webapp, every action is an isolated transaction. Two salespeople log a sale at the same time without conflict. The database guarantees integrity. There’s no “oops, I accidentally deleted everything”. There’s a change history and backups. And if someone messes up, you can revert that specific action without affecting everyone else’s work. In a spreadsheet, one person’s Ctrl+Z undoes another person’s change.

2. You rely on copy-pasting between tabs

The workflow: customer places an order (sales sheet) -> pick the product (inventory sheet) -> log the payment (finance sheet) -> generate an invoice (another sheet). Each step is copy and paste. Each copy is a chance for error.

In a webapp, the order is entered once. The system updates inventory, logs the payment, and generates the invoice automatically. Zero copy-paste. Zero transcription errors. The data is born in one place and flows to the rest of the system on its own.

That’s exactly what integrations do: connect the parts of a process so data moves automatically.

3. The file is slow

A spreadsheet with 10,000 rows and 30 tabs takes forever to open. Freezes on mobile. Locks up when someone runs a filter or a heavy VLOOKUP. If there’s an IMPORTRANGE pulling data from another spreadsheet, it gets worse.

This isn’t “a Google thing”. It’s a structural limitation. Spreadsheets weren’t built to be databases. When you have 10,000 records with 20 fields each, you need a real database. PostgreSQL on Supabase fetches 10,000 records in milliseconds. A spreadsheet takes 30 seconds. And as volume grows, the spreadsheet gets slower. A database, with the right indexes, keeps the same speed with 10,000 or 100,000 records.

4. Sensitive information with no access control

In a spreadsheet, everyone with the link sees everything. A salesperson sees the finances. An intern sees customer data. Someone shares the wrong link and sensitive data is exposed.

In a webapp, each user sees only what they need. Salesperson sees their sales. Manager sees all sales. Finance sees the numbers. Admin sees everything. It’s not a complex setup. With RLS on Supabase, it’s a few lines of SQL per profile.

If your company handles customer data (SSN, addresses, payment info), having that in a shared spreadsheet is a real risk — both for leaks and for regulatory compliance.

5. You spend time building reports

If every Friday someone stops to copy numbers from 3 spreadsheets, build a chart in Google Sheets, format it, and send it by email — that time has a cost. It’s 2-3 hours per week, 8-12 hours per month, 100+ hours per year. At $15/hour in employee cost, that’s $1,500/year on a task that a dashboard solves in real time.

On FitPlan, the management dashboard shows active students, inactive students, new signups this month, and pending renewals in real time. Nobody builds reports. The numbers are always up to date. The time that would go toward reports goes toward management.

What a webapp does that a spreadsheet doesn’t

Per-user access control. Each person sees only what they need. No leak risk, no confusion.

Data validation on input. An email field only accepts emails. A currency field only accepts numbers. Dates must be in the right format. A spreadsheet accepts anything in any cell. A webapp prevents errors before they happen.

Automations. Order confirmed — update inventory, notify the seller, send the customer an email. All automatic, no copy-pasting.

Fast search and filtering. 10,000 records filtered in milliseconds. Try doing that in a 30-tab spreadsheet.

Works well on mobile. A responsive webapp works on phones. A 20-column spreadsheet on mobile is unusable.

Per-user change history. Who changed what, when. In a spreadsheet, version history exists but doesn’t show who changed each cell.

Integrations. Connect with payments (Asaas), shipping (Melhor Envio), WhatsApp (Zapi), email (Resend). A spreadsheet can connect through Zapier/Make, but it’s duct tape on top of duct tape.

The invisible cost

The cost of a spreadsheet is invisible because nobody accounts for it. But it’s there:

Time on manual work. Copying data between tabs, building reports, fixing broken formulas. How much does the team spend on this per week? Multiply by 52 weeks. The number is scary.

Data errors. A salesperson typed the wrong amount, finance didn’t catch it, the invoice came out wrong. How much does it cost to fix? How much does it cost in credibility with the client?

Missed opportunities. A decision that could be made with real-time data gets delayed because “the report comes out Friday”. By Friday, the opportunity is gone.

Limited scale. The company grows, hires more people, and the spreadsheet that worked for 3 people doesn’t work for 10. Each new person adds more complexity to the spreadsheet. In a webapp, it’s just creating another login. And the new employee starts with access restricted to what they need, with no risk of touching things they shouldn’t.

Team turnover. An employee leaves, another one starts. With a spreadsheet, the new person needs to understand the formula logic, the tab organization, the workarounds the previous person built. In a webapp, the flow is guided. The system tells you what to do at each step. Onboarding time drops from weeks to hours.

A custom webapp has an upfront investment (real price ranges here), but the return shows up fast: less rework, faster decisions, fewer human errors, team focused on the work that matters.

When NOT to migrate

Not everything needs to become a system. If the spreadsheet works fine, has few users (1-3 people), and the data volume is low (under 1,000 records), there’s no reason to overcomplicate things.

Premature migration wastes money. The MVP of a system costs $3-8k. If the spreadsheet works for another 6 months, invest when the process actually calls for it.

Migration makes sense when:

  • More than 3 people depend on the same spreadsheet daily
  • Data volume exceeds 1,000 records
  • There’s sensitive information (customer data, financials)
  • The process has more than 3 manual steps that could be automated
  • You spend more than 2 hours per week on spreadsheet maintenance tasks

If you checked 3+ of those, it’s time.

How the migration works in practice

The process I follow with clients:

First, mapping the current process. Before thinking about screens and technology: how does it work today? Which spreadsheets exist? Who uses them? What’s the data flow between them? Where does it get stuck?

Then, defining the system scope. What does the system need to do in the first version, and what can wait. MVP first, evolution later.

Then comes the webapp development. With the mapping data, I build the system that replicates and improves the existing process. I migrate the historical data from the spreadsheet to the database.

Team training. A new system only works if the people using it know how to use it. I record short videos of each flow and run a live onboarding session.

Transition period. Spreadsheet and system run side by side for 1-2 weeks. The team uses the system and falls back to the spreadsheet if needed. This provides security and allows for adjustments.

Finally, shutting down the spreadsheet. When the team is comfortable and the data checks out, the spreadsheet becomes an archive. Backup saved, but nobody opens it anymore.

The whole process takes 4 to 8 weeks depending on complexity. The key point: the system is built on top of the process that already works, not the other way around. I don’t force the company to change how they work. I automate what they already do, removing the manual and error-prone parts.

And after deploy, the system evolves. The first version solves the most urgent problems. In the following months, with the system running and the team using it, improvements come up that nobody had thought of before. A new filter, a different report, an automation that saves even more time. The webapp grows with the company. The spreadsheet doesn’t.

Next step

Need a dev who truly delivers?

Whether it's a one-time project, team reinforcement, or a long-term partnership. Let's talk.

Chat on WhatsApp

I reply within 2 hours during business hours.