Build or Buy?
A spreadsheet that several people edit at once looks like a WebSocket and a broadcast. It is the most expensive feature many products never planned for.
Published on October 5, 2026
The question
Your users want to work on spreadsheets together, inside your product, with their data in your database. You have a data grid already. How hard can the rest be?
This post lists what "the rest" is, so the decision is made with the full scope in view.
The first week
A WebSocket server relays each edit to the other users of the document, and a timer saves the document to the database. The demo works: two windows, one changes a cell, the other updates.
The months after
Ordering. Two users edit at the same moment; both apply their own change first. Without a single authority that orders operations, the two screens stop agreeing, silently.
Structure. Inserting a row is not a cell edit. Every reference below it moves, formulas are rewritten, merges and styles shift. A concurrent insert from another user must land in the right place on every screen.
Formulas on the server. A server that relays messages does not know that D7 is =SUM(D2:D6). When your backend or an AI asks for the total, someone must compute it, which means running the spreadsheet engine on the server, with the same results as the browser.
Persistence. Saving the full document on every change is simple and stops scaling as documents grow. Saving operations instead means mapping every spreadsheet method to an update of your storage, and keeping that mapping right as features are added.
Reconnection. A laptop sleeps for an hour. The client must find out what it missed and catch up without corrupting the document.
Everything around it. Permissions per document, sharing and invitations, an API for other systems, images stored outside the document, snapshots, comments. None of it is the spreadsheet, all of it is needed to ship.
And now AI. Users expect an assistant that works on their data. That is a model integration, tools that change the document safely, conversations, attachments, and budgets so one user cannot spend the month's credits.
What Jspreadsheet Server covers
The server is a set of Node.js packages that cover those parts and leave you the decisions that belong to your product:
| Concern | Provided | Yours |
|---|---|---|
| Ordering and conflicts | A sequencer per document, last-write-wins at cell level, convergence by replaying the same sequence | — |
| The live document | The Jspreadsheet engine, headless, with 500+ functions | — |
| Persistence | Per-operation adapters for MongoDB, PostgreSQL and Redis | The database, or five handlers for another |
| Identity | Three hooks that receive each request's token | Your login and your rules |
| Integration | A REST API over every worksheet module | Your jobs |
| AI | An agent with spreadsheet tools, an MCP server, a PROMPT formula | The model, the budget |
| Scale | Partitioning by document, no coordination layer | Your infrastructure |
The full list, with links to each part, is in Why Jspreadsheet Server.
What stays yours
The usual worry with buying is losing control. The server is designed so that the parts that matter stay in your hands:
- Documents are stored in your database, through an adapter.
- The server has no user table. Your hooks decide every request.
- It runs where you deploy it, including networks with no internet access.
- AI keys live in your server config, and you choose the model.
Decide with the full scope
Building makes sense when collaboration is your product's core and you will staff it for years. If spreadsheets are a capability your product needs, the months above go to your product instead.
To see the result, open the Intrasheets demo in two windows, or run the reference application on your machine with Docker.