Why code should never read B7

[ImJeremyHe]

Why code should never read B7

TL;DR

I think humans and software break spreadsheets in different ways because spreadsheets lack structure.

LogiSheets adds typed blocks directly into the grid so users can still model with spreadsheets while software can safely read structured data.

Demo (Factory Simulator):
https://www.logisheets.com/

The spreadsheet backing the simulation can be revealed from the top-right corner.

---

I've been bothered by the same property of spreadsheets for years: they're at once too flexible for humans and too fragile for software.

A person can overwrite a formula, type "N/A" into a quantity column, or accidentally break a calculation. Nothing stops them. The mistake often isn't discovered until much later, after it has already affected downstream results.

Software has the opposite problem. It reads a value from B7, someone inserts a row above it, and now the program is silently reading the wrong number. Humans think in records and fields. Software ends up reading coordinates.

These look like different failures, but I think they're the same bug.

The spreadsheet grid has no structure.

Every cell can contain anything. Rows and columns don't have stable identities. A value's meaning exists only by convention. Humans are expected to follow the convention, and programs are expected to guess it.

What if spreadsheets had structure?

The traditional answer is to move the data somewhere else.

Databases, Airtable, and similar systems introduce schemas, types, constraints, and stable records. The tradeoff is that the user is no longer working in a spreadsheet.

That solves the software problem, but it often removes the thing spreadsheets are uniquely good at: building live models directly in the grid.

My goal with LogiSheets is different.

Instead of replacing the spreadsheet, I want to add structure directly into it.

Regions of the sheet become typed blocks. Fields have names. Values have types. Rules can constrain what users are allowed to enter. Records have stable identities independent of their physical position in the grid.

The important part is that the same structure serves both humans and software.

A user cannot accidentally enter invalid data into a field.

A program can read:

orders["A-103"].qty

instead of:

B7

Rows can move. Columns can move. Data can be reorganized for readability. The program still reads the same record.

Delete a row and it becomes a removed record, not silent corruption.

One structure. Both sides stop breaking.

It's still a spreadsheet

I don't want to turn spreadsheets into forms.

Users should still be able to write formulas, build models, run scenarios, and experiment with ideas directly in the grid.

The engineer constrains the shape of the result.

The user keeps the flexibility of a spreadsheet.

The software gets something it can trust.

How far can the model go?

One question I had early on was whether this idea only works for simple business records.

To test it, I built an entire factory simulation on top of the model.

Production chains, inventories, bottlenecks, and planning logic are all represented as structured spreadsheet blocks. Users can edit values, formulas recalculate instantly, and the entire state can be saved into a standard .xlsx file and loaded again later.

That experiment convinced me that the idea stretches much further than data entry forms.

Demo (Factory Simulator):
https://www.logisheets.com/

The spreadsheet backing the simulation can be revealed from the top-right corner.

2026-06-16.14.49.51.mov

How this differs from existing approaches

Excel Tables and Named Ranges

Excel Tables give names to regions of the sheet, which is useful.

But names are not guarantees.

A column can still contain unexpected values, broken formulas, or references that no longer make sense. Validation rules are optional and easy to remove. Software still has to trust that the workbook's structure hasn't drifted.

Airtable and Grist

These systems introduce real structure and constraints.

The tradeoff is that they move data into a database-style model.

LogiSheets attempts to keep the structure inside the spreadsheet itself.

Parsing spreadsheets from code

Libraries such as pandas or spreadsheet parsers can read workbook contents after the fact.

They don't prevent the workbook from drifting away from the assumptions your code makes.

The validation happens after the mistake.

I want the structure to exist before the mistake.

Current status

LogiSheets is implemented with a Rust core compiled to WASM and runs entirely in the browser.

It reads and writes real .xlsx files.

Some parts are working well. Some parts are still rough. There are many things I haven't tested yet.

What I'm most interested in right now is feedback on the idea itself:

Is the lack of structure actually the root cause of the problems people encounter when spreadsheets meet software?

I'd love to hear where this resonates, where it doesn't, and what existing tools you think already solve this problem well.