Levels.fyi Scaling with Google Sheets

Levelsfyi's early use of Google Forms and Google Sheets is a good reminder that scale problems do not all arrive on day one. A product can reach real traction with tools that look unsophisticated from the outside if those tools match the actual workload, keep the team fast, and avoid premature operational overhead. The interesting part is not that a spreadsheet became a permanent database. It is that the team deliberately traded backend sophistication for speed of iteration while the product was still proving demand.

Why Sheets worked at first

For an early compensation data product, the first hard problem was collecting structured submissions and publishing useful comparisons, not designing a perfect storage layer. Google Forms gave the team a ready made input path. Google Sheets gave them a shared data table with version history, access control, and a familiar editing surface.

That combination solved several startup problems at once. Non engineers could inspect and clean submissions. Schema changes were lightweight. There was no database administration, migration framework, or backend deployment burden for the core data collection loop. In other words, the system optimised for operational simplicity more than for theoretical scale.

What the architecture probably looked like in practice

The public site still needed an application layer. Sheets is not serving millions of dynamic page views directly. A realistic pattern is to treat Sheets as an operational datastore or admin surface while serverless functions, caching, and static generation handle user traffic. The app can periodically pull structured rows, precompute aggregates, and publish those results into a faster read path.

That distinction matters. Many unusual early architectures work because the public read path is decoupled from the place where editors manage source data. A spreadsheet may be the source of truth for a time, while cached JSON, static pages, or edge responses absorb most of the audience scale.

The real benefits

Using commodity tools changes team economics. Small teams can ship product changes without waiting on database migrations, internal admin panels, or specialised data tooling. If the product surface is mostly read heavy and the write rate is modest, the bottleneck may be product clarity rather than database throughput.

There is also a trust benefit. Sheets makes the data visible. When founders are still learning what data quality checks matter, a transparent table can be more valuable than an elegant but opaque backend.

Where the approach breaks down

Spreadsheets are poor at concurrency control, typed invariants, and complex relational access patterns. They are also vulnerable to accidental edits, row level audit gaps, and quota or API limitations. Once the product needs transactional updates, richer access control, or heavy write automation, the convenience starts turning into operational friction.

Another constraint is data modelling. A spreadsheet encourages denormalised tables and manual clean up. That is manageable for a period, but harder once multiple workflows depend on the same entities.

The architectural lesson

This story is not really about Google Sheets being secretly scalable. It is about matching infrastructure to the current source of risk. Early on, the risk was shipping too slowly and overbuilding. Later, the risk would shift toward correctness, maintainability, and richer product logic, at which point a more conventional backend becomes worthwhile.

The right takeaway is therefore practical: use the simplest system that preserves product momentum and data quality for the stage you are in. The wrong takeaway is that spreadsheets are a universal replacement for databases. They are not. They are a way to postpone complexity until the business can justify it.