Why a custom spreadsheet on a website breaks on real data
A custom spreadsheet on a website usually passes the demo and breaks on the very first real file. The reason is not the layout but the data model: developers store cells as markup or as a flat list of values, whereas a built-in spreadsheet is a dependency graph between formulas. While there are only a dozen formulas, the recalculation order doesn't matter.
As soon as chains like "column total → sheet summary → dashboard metric" appear in the sheet, the browser-based spreadsheet editor starts computing them in the order the cells appear, and intermediate values end up in the result as stale. The user sees a number that doesn't match the adjacent one and stops trusting the tool.
The second class of failures is volume. Pasting several thousand rows from the clipboard through a separate handler for each cell freezes the tab: the browser redraws the entire grid on every change.
This calls for virtual rendering — only the visible rows live on screen, while the model stores data separately from the view. Without this, formula recalculation and array pasting compete for a single thread, and the interface freezes for tens of seconds.
The third and most costly failure is data loss during export. If the export collects values from the rendered cells, rows outside the visible area won't make it into the file, and formulas will come through as text.
The user gets a document that looks like the original but contains different numbers — and only finds out after sending it to the counterparty.
All three failures are fixed at the architecture level, not with spot patches: a separate sheet model, topological sorting during recalculation, lazy rendering, and export from the model rather than from the DOM. Let's break down how this is handled in practice.
What a mature spreadsheet delivers: speed, integrity, export
A mature spreadsheet differs from a "table on a website" in three measurable things: recalculation time, the share of lost edits, and the predictability of import-export. Let's break down each one.
Recalculation speed
Formulas are not computed at render time but in a separate layer: dependencies between cells are stored as a graph, and when an edit is made, only the affected branch is recalculated, not the entire sheet.
On workbooks with tens of thousands of cells, this is the difference between an "instant" response and "a second for every keystroke." Heavy operations — pivot tables, range search, conditional formatting — are moved to a background thread, and the interface stays responsive.
Data integrity
Edits go through a queue with confirmation: until the server has committed the change, the cell is marked as "unsaved." If the connection drops or the tab is closed, nothing is lost — when the user returns, they see their values.
Conflicts from simultaneous editing are resolved by cell version, not by "whoever overwrote last." The share of lost edits goes to zero, rather than to "sometimes it disappears."
Import and export
Files are read in a streaming fashion, so a workbook with hundreds of thousands of rows does not crash the tab. Formulas, formats, merged cells, and sheets are transferred without manual touch-ups.
Export delivers the same result that the user sees on screen — the discrepancy of "the file doesn't match the interface" belongs to the class of failures that is closed by tests on the customer's real workbooks.
It is exactly this level that Spreadsheet provides as a product component, rather than as an embedded viewer.
Approaches to spreadsheet: ready-made engine, custom editor, hybrid
The choice of option is determined not by the "beauty" of the interface, but by which operations are critical: formula recalculation, collaborative editing, import-export, data volumes. Below are three real paths that are chosen between at the start of a project.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made engine (table libraries) | A working editor is needed quickly: input, a basic set of formulas, sorting, filters, copying ranges | Complex formulas and recalculation of large workbooks run up against the engine's capabilities; deep modifications of behavior — through wrappers, not by editing the core |
| Custom editor | Non-standard logic: custom functions, binding cells to system data, specific input validation | Longer to first release; formulas, dependencies, and recalculation are written and tested manually |
| Hybrid | A ready-made interface is needed, but with extensions for business rules | Requires a careful boundary: what lives in the engine, what lives in our layer, otherwise updates break the modifications |
A ready-made engine covers 70–80% of typical scenarios: input, navigation, basic formulas, export. Beyond that begins the zone where what matters is not the library but the layer on top of it — validation, cell permissions, connection to server data.
In practice, the hybrid approach gives the best balance: we take the interface and recalculation from a proven engine, while business logic — custom functions, input restrictions, integration with the accounting system — is kept as a separate layer.
This way, updating the engine doesn't break the modifications, and formulas and rules remain under our control.
The key question when choosing is where the formula will be calculated: in the browser or on the server. This determines how large workbooks and collaboration will behave. We break down how this affects the architecture and what to plan for in advance.
How we implement spreadsheet: from data audit to handover
Implementing a spreadsheet starts not with choosing a library, but with a data audit: which entities already exist in the system, what relationships there are between them, and where the source of truth is.
If this stage is skipped, the table on the site turns into a parallel database that diverges from the main one within a couple of weeks. That is why we first lock down the data model and only then move on to the interface.
- Audit of data and scenarios. We analyze who edits what, which rows come from outside, and which are entered manually. The output is a list of sheets, cell types, and access rules.
- Schema of sheets and relationships. We design the structure: which sheets reference each other, where aggregates are calculated, and how versions are stored. The schema is agreed with the client before the first line of code.
- Setting up the table engine. We connect the spreadsheet component, configure cell types, input validation, formulas, and dependency recalculation. Separately, we handle collaborative editing and version conflicts.
- Testing formulas and edge cases. We run the formulas on real volumes: empty cells, division by zero, circular references, large ranges. We compare the results against the client's reference calculations.
- Import and export. We set up loading from files and exporting to familiar formats while preserving formulas and formatting, so that data is not lost at the boundary.
- Load testing. We look at how the table behaves at the limit of rows and concurrent users, and where recalculation slows down.
- Handover and training. We provide documentation on the sheet schema and operating rules, and show the client's team how to add sheets and formulas without a developer.
Each stage ends with an artifact: a schema, a configuration, or a verification report. This makes it possible to return to any step and understand why the table is structured exactly this way.
What the client receives after spreadsheet implementation
Spreadsheet implementation is not just a working editor on the page, but also a set of artifacts by which the system can be developed, handed over, and verified without us. Below is what exactly remains with your team.
- Table configuration. The structure of sheets, cell types, formulas and recalculation rules, reference data and validations — as configuration files under version control, rather than "set up by hand in the interface." Changes go through review and can be rolled back.
- Data and relationship schemas. How sheets are connected to each other, where values are pulled from, where the boundaries of recalculation are — a diagram and description by which a new engineer can introduce changes without deciphering someone else's code.
- Access policies. Roles for reading, writing, and administration, separation by sheets and ranges, rules for collaborative editing and locking. It describes who sees what, and how this is verified.
- Export and data exchange. Export formats (XLSX, CSV), import rules, handling of conflicts and duplicates, limits on size and operation time — with examples and test sets.
- Documentation. Administrator and user guides, description of formulas and limitations, instructions for typical operations — in the repository alongside the code.
- Support regulations. Procedure for updating libraries, backup, monitoring of recalculation errors, incident response times, and rollback points.
- Test scenarios. A set of checks for formulas, access rights, and export — so that changes do not silently break calculations.
Each item is handed over to your infrastructure with access and a walkthrough. Describe the task — we will come back with an estimate and a plan.
Case study: how a spreadsheet stopped losing edits during collaboration
The customer came with a complaint: when several employees worked simultaneously in the same spreadsheet, some changes disappeared. Edits were saved "into the void": the user saw a confirmation, refreshed the page — and their row rolled back to the previous state.
Recalculating formulas after every input took seconds, and exporting to a file sometimes returned a stale snapshot.
We dug into the mechanics. The data was stored as a single document, and each client overwrote it entirely — whoever saved last "won," and the rest of the edits were wiped out.
Recalculation ran across the entire sheet on every keystroke, and export read the state from a cache that wasn't invalidated on conflict.
What we changed
We switched to a model of individual cells with versioning: each edit is an atomic operation on a specific cell, not a rewrite of the document.
Conflicts are resolved by modification time, not "last write wins." Recalculation became incremental — only dependent formulas are recalculated, not the entire sheet. Export now assembles a snapshot from the current state with a lock held for the duration of the export.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Share of lost edits | ~7% of sessions | 0 |
| Sheet recalculation time | 3-5 sec | < 300 ms |
| Discrepancies in export | periodically | none |
A month after implementation, the customer's team stopped keeping a parallel copy of the spreadsheet "just in case" — trust in the data was restored.
We work on a Spreadsheet stack with shared state and cell versioning, so scenarios like this are a routine task for us, not an experiment.
How is a spreadsheet different from a regular HTML table?
A spreadsheet is a calculation engine with a tabular interface, while an HTML table is static markup. <table> stores values in cells as text: the browser will render them, but it won't know that one cell holds a total and another holds an addend.
As soon as the user changes the source data, there is nothing to recalculate — all the logic remains on the server or on the developer, who manually rewrites the numbers.
In a spreadsheet, there is a dependency graph between cells.
The formula =SUM(B2:B10) doesn't just add up numbers — it subscribes to a range, and when any cell within it is edited, the engine marks the dependent nodes as "dirty" and recalculates only them, not the entire sheet.
This is where chains come from: price × quantity → row total → invoice total → tax. A regular table simply can't handle this, because it has no model of relationships — only the order of cells in the markup.
The data requirements diverge further as well. An HTML table lives happily on static content: a price list, a schedule, a reference guide. A spreadsheet is needed where values change and influence each other — estimates, calculators, financial models, load plans.
Here, cell types, error handling (#DIV/0!, circular references), number and date formats, and what happens when recalculating a large sheet all become important: naively traversing all formulas on every keystroke turns input into a slideshow.
Collaborative editing adds another layer. An HTML table has no state that can be synchronized — edits simply overwrite the markup.
In a spreadsheet, two edits to the same cell conflict by value, not by cursor position, and the engine must converge to a single result without "lost" recalculations.
That's why the choice between a spreadsheet and an HTML table is a choice between "displaying data" and "letting the user calculate," and substituting one for the other shows up precisely in formulas and cell dependencies.
Technical doubts about the spreadsheet: breaking it down point by point
Before the customer's team approves the architecture, a dozen "what ifs" usually come up: will the table handle the real data volume, won't it turn into a security hole, and how will it live alongside the accounting system. Below are answers to the doubts that most often decide the fate of a project.
Will the browser handle a table with tens of thousands of rows?
Yes, if it's counted correctly. Virtualization renders only the visible rows — dozens of cells live in the DOM instead of tens of thousands, so scrolling stays smooth.
Heavy formula recalculations go to a separate thread, and dependencies between cells are stored as a graph: when you edit, only the affected branch is recalculated, not the entire sheet.
In practice, sheets with 50–100 thousand rows with formulas open and are edited without slowdowns — the bottleneck becomes not rendering, but carelessly written formulas.
Where are formulas executed, and can the result be trusted?
Formulas are calculated in an isolated environment with time and memory limits — a single "looping" formula won't hang the tab.
If calculations must be consistent for everyone, the engine is moved to the server: then the result is the same regardless of the browser, and the version history records who changed what.
How does the table connect with the accounting system and access rights?
Data travels through the API: reference data is pulled from the accounting system, and calculation results are returned back. Rights are inherited from the customer's roles — at the level of the sheet, range, and individual cell, with a change log. This closes the question of "who saw and edited the row."
What about input security and export?
User input is escaped, macros and external links are not executed — the table does not become a channel for third-party code. Export to familiar formats is done with type checking so that formulas don't "break" during export.
Describe the task — we'll come back with an estimate and a plan: which sheets, what volume, what we integrate with.
Let's discuss your spreadsheet task
To come back with an estimate and a plan rather than generalities, we need to understand the nature of the spreadsheet: how many sheets, what formulas are in use, where the data comes from and where it goes.
A spreadsheet on a website is not "a table for the sake of a table," but a specific set of calculations, access rights, and export scenarios, and it is these that determine the scope of work.
Describe the task in free form — we will ask clarifying questions ourselves afterward:
- what operations users perform: input, formula recalculation, pivot tables, filters, collaborative editing;
- where the data comes from and where it goes: manual input, file uploads, integration with an accounting system, export to a file or to an external service;
- whether server-side recalculation logic is needed or the calculation is entirely on the browser side;
- how rights are separated: roles, access to individual sheets and cells, change history;
- what volumes: number of rows and columns, concurrent users, recalculation frequency;
- fault tolerance and data preservation requirements: autosave, versions, recovery after a failure;
- whether there is a ready prototype, sample file, or description of the formulas currently in use.
Based on these answers, we assemble a work plan: the data schema, the choice of approach to formula recalculation, access separation, export scenarios, and the order in which features are delivered by stages.
The estimate is based on the volume of formulas and integrations, not on the number of screens — so it is important to see a real example of the spreadsheet your employees work with.
Send a description and, if available, a sample file — we will come back with an estimate, a work plan, and a breakdown by stages.
