Every dev has seen it: a business running its entire operation on a 40-tab Excel file named Orders_FINAL_v2_REAL.xlsx. The 'Excel person' holds it all in their head, formulas break silently, and month-end reporting is a three-day copy-paste ritual. Here's the playbook we use at aimEncoders to replace those spreadsheet monsters with proper web apps — the architecture, the migration pattern, and the lessons that only show up in production.
Step 0: Find the Real Workflow Under the Sheets
A 40-tab spreadsheet is never one system. It's three or four tangled together — orders, inventory, staff, reporting — joined by VLOOKUPs and prayer. Before writing code, we map every sheet and interview the people who actually use them. Half the sheets are usually obsolete; the rest reveal the actual entities: customers, orders, products, users, approvals.
Lesson: data modeling is the project. The UI is the easy part. If you get the entities and relationships right, everything downstream is straightforward. Get them wrong and you're rebuilding in six months.
The Stack: Boring on Purpose
Our standard replacement stack:
- Next.js (App Router) — server components for dashboards, server actions for mutations, one deployable unit.
- PostgreSQL — the moment you need concurrent writes, audit trails, and real constraints, you need a real database. Spreadsheet 'databases' have none of these.
- Auth with row-level permissions — managers see margins, staff see their tasks. We use role-based access with row-level security policies so the permission model lives in the database, not in hopeful frontend checks.
- Background jobs — reminders, report generation, and integrations run on a queue, not in someone's browser tab.
Lesson: the least technical person on the team is your real QA benchmark. If the warehouse staff can't use it on a phone, the architecture doesn't matter.
The Hard Parts Nobody Warns You About
Data cleanup is 40% of the work. Years of free-text entries mean 'Acme Corp', 'ACME', and 'acme corp.' are three different customers. We build a dedicated import pipeline — parse with SheetJS, normalize, dedupe with fuzzy matching, and show a human-readable diff before anything touches the production database. Never trust a direct import.
Parallel runs, not big-bang cutovers. We run the new app alongside the old sheets for a few weeks. The team uses both; discrepancies get investigated, not argued about. The spreadsheet retires — it doesn't get executed on a Monday morning.
Audit trails are a feature, not a nicety. The first time someone asks 'who changed this number?', the audit log pays for itself. We log actor, timestamp, old value, new value on every meaningful mutation. Spreadsheets can't do this; it's one of the strongest arguments for the migration.
Test the workflows, not just the endpoints. We run Playwright end-to-end tests over the critical paths — submit order to approve to dispatch — because that's what the business actually does. (We wrote up our full testing approach here: https://aimencodersblog.blogspot.com/2026/10/why-we-test-every-website-like-its.html.)
The Honest Decision Rule
Not every spreadsheet deserves a web app. Our rule of thumb:
- Keep Excel when the workflow is simple, users are few, and errors don't hurt.
- Improve the setup (templates, validation, access controls) when that solves it.
- Buy off-the-shelf when an existing product covers most of the workflow.
- Build custom when the process is business-critical, systems need to integrate, and existing tools would need costly compromises.
The migration that works is phased: replace the single most painful workflow first, deliver value in weeks, and let the savings fund phase two. If you want the full non-technical breakdown of the business case — the 7 signs, the cost math, the migration steps — it's here: https://aimencodersblog.blogspot.com/2026/10/from-spreadsheets-to-web-apps-when-to.html in our services overview, or read the companion piece this post is adapted from.
Muhammad Asad Ullah is the founder of aimEncoders, a web development agency in Faisalabad, Pakistan building QA-tested custom websites, custom web applications that actually convert, and business automation tools.
Top comments (0)