Replacing Excel with a web app: from spreadsheet debt to a production-ready application

When your Excel file needs to become a production app

Excel is a brilliant tool. For modelling a calculation, analysing a dataset or setting up a one-off report, it is remarkably quick. Many business-critical processes started life as a spreadsheet: a quotation calculator, a timesheet tracker, a stock list, a commission calculation. That worked. Until the organisation grew.

The tipping point rarely arrives all at once. It builds up through small frictions. Two people open the file at the same time and one person's changes overwrite the other's. A colleague drags a column across and breaks a formula. The macro that builds the monthly report suddenly stops working after an Office update. An external party sends their version as an attachment and nobody knows which file holds the truth. This is what software engineers call spreadsheet debt: technical debt that accumulates in a tool never designed for the job.

At that point, it is time to rebuild the spreadsheet as a proper application. Not as a rejection of what Excel did well, since your existing logic represents years of business knowledge, but as a formalisation of it in an environment that can handle multiple users, audit requirements and growing data volumes. We manage that transition for you: a web application that carries the business logic from your worksheets across, with an interface your team understands straight away, and a database that ensures no record ever quietly disappears.

Migration approach: moving data and logic out of your worksheets

An Excel file is more than a table of figures. It contains business logic hidden in formulas, rules of thumb built into conditional formatting, and exceptions that live in comments or hidden columns. Simply exporting the data and pumping it into a new application loses that knowledge. Our migration approach is about carefully uncovering it.

In the first phase we carry out what we call business-logic-discovery: we walk through every formula, every named range, every macro and every pivot table field. A SUMIFS with four criteria is not a technical detail; it is a business rule. We document what that rule means in plain language, check with you that it is still current, and then translate it into code for the new application. This exercise often surfaces rules that nobody consciously knew about any more, or rules that are outdated and can be dropped.

We also tackle data extraction, which is more work than a CSV export. We map the implicit schema of your worksheet: which columns logically belong together, which are calculated versus source data, and where duplicates or inconsistencies lie. We then design a normalised Postgres schema in which each entity gets its own table, with foreign keys, constraints and indexes in the right places. Where in doubt, we run the old Excel file and the new system in parallel for a period to verify that the outcomes match.

For processes that must be idempotent, such as generating invoices, sending emails or firing off API calls, we build in explicit safeguards. A double click must never create two invoices. Excel cannot guarantee that; a well-designed web app can.

Common Excel files we replace

We see the use cases below come up every week at SMEs and larger organisations. Do you recognise your own spreadsheet? The solution most likely follows a familiar pattern.