In many organizations the real intellectual property is not on the website. It lives in a spreadsheet: a pricing model, an eligibility calculator, a planning tool, a method that took years to refine. It works — but only for the few people who know which cell not to touch, and only on the computer where the file lives.
Turning such a workbook into a web application opens it to everyone: no installation, every language, every device. It also raises one hard question. How do you know the web version calculates exactly what the spreadsheet calculates?
Why not simply embed the spreadsheet?
Embedding a workbook or running it through a spreadsheet service is tempting, but it carries the old limitations into the new world: the same opaque cells, poor performance on phones, no real translation, no guided explanations and a permanent dependency on a third-party service. If the calculation is the heart of the product, it deserves to become software.
Step 1: inventory before code
The first weeks are spent reading, not writing. Which sheets are inputs, which are intermediate steps, which are results? Which formulas depend on which? Where are lookup tables, and where are values typed in by hand? For a workbook of 56 sheets and roughly 65,000 formulas, this map is the foundation for everything that follows.
Step 2: port the logic, not the cells
A spreadsheet expresses a method through thousands of cell references. Copying those one by one produces code nobody can maintain. Instead, each sheet is understood as a function: what goes in, what comes out, what the rule is. The result is a calculation core of readable, named functions — one core, regardless of how many languages the interface speaks.
Step 3: let the original produce the reference values
Trust comes from comparison. The original workbook is run automatically — headless, through an office suite — across a wide range of inputs, and every result is stored as a reference value. These references are the contract the new engine has to honour.
Step 4: compare everything, on every change
The web engine computes the same inputs and a test suite compares its output with the references. Not a sample — every field. On our reference project, more than 73,000 fields are checked against the values the original produced, and the build stops if a single one differs. Every later change to the code runs through the same check before it can go live.
Step 5: make the calculation visible
A spreadsheet shows numbers; a web application can show reasoning. Once the engine is trustworthy, the interface can do what the workbook never could: guide newcomers through levels from foundations to mastery, explain each step in plain language, and animate the path from input to result so people understand how it is reached.
Step 6: translate the interface, never the engine
Languages belong to the interface. The calculation core stays single and language-neutral, while terms, explanations and labels come from translation files. That way five language versions can never calculate five different results.
Checklist
- 1.Map every sheet: inputs, intermediate steps, results, dependencies.
- 2.Rewrite each sheet as named functions instead of copying cell references.
- 3.Generate reference values from the original across a wide input range.
- 4.Compare every field automatically and block releases on any difference.
- 5.Keep one calculation core; translate only the interface.
- 6.Use the freed-up transparency: guided levels, explanations, visible calculation paths.
The spreadsheet does not disappear — it becomes the referee. And the knowledge that used to sit in one file on one computer becomes something everyone can use.