Merge Sheets is a research project that explores the question, “If spreadsheets were invented today, what would they look like?”. You can go check out the current demo here: https://app.mergesheets.com

Motivation

Since I started my career as a Mechanical Engineer, I have long had a reverence for spreadsheets. They are the most accessible general purpose compute primitive available to non-software developers and large swaths of the modern economy is run on top of them.

Throughout schooling and my early career I was an avid user of excel and google sheets. I have also developed extensively against them as a software developer, even building an entire app with google sheets at its core.

As I have become more experienced as a software engineer now I have been increasingly curious to peak behind the curtains of what makes spreadsheets tick and what drives many of the constraints and sharp edges I have previously run into as a power user.

Brainstorming

In late 2025 to early 2026, with the step function increase in AI capabilities and some extra free time around the holidays, I decided it was time to partake on this journey of understanding. I was also going to use this process to explore some new AI driven development techniques making the rounds at the time and see if there was any substance to them.

Before starting any research, I built out an initial feature set that I believe should be the basis of any modern spreadsheet app. These included:

• Offline / Local first editing experience
• Seamless online collaboration
• Git-like version control for forking, merging, point-in-time recovery
• General compatibility with existing spreadsheets (excel, sheets, etc.)

There were many more nice-to-haves and interesting feature extensions, but this gave me a good starting point to derive requirements and ground research.

Research

Next came the research phase. This was the first place where AI became super helpful in finding and condensing large amounts of data and documents into a digestible format in a short period of time.

I started by digging into how the incumbents actually work under the hood. The goal was to understand why my desired feature set isn’t already standard in the market and what constraints I would need to break to get there.

Microsoft Excel

Excel started life in 1985 as a single-user desktop application, and despite forty years of evolution, that DNA still shows. The xlsx format is fundamentally a single-author document that was retrofitted for the cloud. Co-authoring works, but only when files live on OneDrive or SharePoint, and the experience differs significantly between the desktop, web, and mobile versions. The web version in particular is missing major chunks of functionality that power users rely on. There is no real merge conflict resolution; if two people edit the same file offline, you end up with duplicate copies. Version history exists through OneDrive but is shallow and not designed around branching or point-in-time recovery in any meaningful sense. And of course, all of the collaborative features sit behind a 365 subscription.

Google Sheets

Sheets launched in 2006 and was browser-first from day one, which gave it a structural advantage on collaboration. Real-time editing is powered by Operational Transformation (OT), where every edit gets serialized through a central server so all clients converge on the same state. This is great for low-latency multiplayer, but it has some hard limits. Because everything has to flow through the server, true offline work and forking are architectural non-starters. The offline mode that does exist has to be pre-configured per file and is best-effort. Browser-based execution caps performance on larger sheets, and there is no concept of merge conflict resolution because the architecture sidesteps the problem by always serializing edits in a single linear history.

Why a ground-up rebuild

The pattern across both is clear. The constraints I cared about (offline-first, true forking and merging, point-in-time recovery, ownership of data) are not features you can bolt onto an architecture that wasn’t designed around them. They are downstream of the data model. If the underlying primitive doesn’t handle concurrent, divergent histories as a first-class concept, no amount of UI work will get you there.

I had previously been aware of Conflict-free Replicated Data Types (CRDTs) from collaborative apps like Linear and Figma, but it became obvious that this was the core primitive I needed to build my app on top of. CRDTs let each replica edit independently and merge later without a central authority, which is exactly the property required for offline-first editing, branching, and real conflict resolution. Luckily there has been a lot of new research done in this area recently. I found Automerge, a Rust-based general purpose CRDT library, and I was off to the races.

Prototype & Benchmarking

I started with a basic prototype. I kept everything in Rust for simplicity and built a simple terminal based UI to test interactions. You can see it in action in this thread:

Once I had the core functionality down, I turned my eye towards performance tuning. I knew from my Mechanical Engineering days that a slow and non-responsive spreadsheet would be a non-starter. Spreadsheets also pose some unique challenges for reactive and parallel computation which was unlike anything I had done before.

In my prototype, I had intentionally chosen more simple and nieve paths where ever possible. I wanted every piece of complexity in this project to be earned.

This is the second place where AI became a huge force multiplier. I could spin up micro benchmarks to test every critical aspect and make the tuning process as data driven as possible.

This included testing:

• memory usage
• storage sizes
• compute bottlenecks
• parallel vs nested function execution
• and many more

Often times, there was not a clear winner. As every great engineer knows, its all about tradeoffs. My traditional engineering background helped a lot here in terms of intuition and understanding what real workloads would look like.

I also reached out to many of my engineering friends who gave valuable feedback about their workloads. This helped early on in the benchmarking, but even more so later on when trying to eliminate the friction they feel in every day use.

Development

Once I felt like I had some solid foundations from the prototype, it was time to move on to the application and feature development. This shifted the app from pure Rust to a WASM based engine run in a Web Worker, and a React based web UI. This choice allowed for quick feedback cycles, easy distribution, and acceptable performance. It also leaves the door open for cross platform native apps in the future.

A lot of the spreadsheet functionality is pretty tablestakes. Things like the 500+ built in functions, keyboard shortcuts, and general UX patterns are deeply ingrained in the muscle memory of power users. It would be a major mistake to try to subvert expectations here.

This is the next place where AI played a major role. Since the models already have a general understanding of what user’s expect, it was a perfect time to test out the Ralph Loop. All of these features could be broken down into micro tasks (implementing a single function or keyboard shortcut) and it was easy to allow the agent to check its work through unit tests or browser automation. Each task was then given to an agent in a fresh context window and automated in a for loop.

This took what would have been years of developer hours and turned it into a few nights of running scripts (and frankly blew my mind in the process). I do think the Ralph technique was uniquely well suited for this problem set and does not generalize well to less well defined domains, but it definitely expanded my thoughts on how to engineer feedback cycles which I have taken on to other projects.

At the end of the day, there is still no substitution for product mindedness, manual testing, and good ol fashion trial and error though. There has been a lot of manual tinkering to get the feel just right, and frankly still a lot to do in this area.

For products designed by and for humans, I think there will always be this last mile problem that has no substitution for taste and attention to detail. It may even become the core differentiator between products.

Current State & Future Plans

As a standalone basic spreadsheet, I am pretty happy with the foundations and performance of MergeSheets. I encourage you to go try out the demo and send me feedback!

Its still missing a lot of functionality before it could actually be used in place of a real spreadsheet. Things like tables, charts, and importing/exporting to other file formats are in the works.

The version control features for branching, merging, and history are all in place but still need to be exposed in the product. Once these are fleshed out a bit more, this could be a truly differentiated experience. It would unlock usecases and ways of working I dreamed about in my previous career.

I also need to build out the server infrastructure for storage and collaboration. This would turn this from a nice demo to a true platform. I plan to make this open sourced and self hostable, allowing for private usecases in government, defense, or healthcare.

I also have some other more “out there” ideas that I think could take things to the next level and take it beyond an excel clone. I will leave these as an imagination exercise for the reader.

AI integrations, API access, and more are all on the roadmap. I plan to continue developing this in my free time and behind the scenes.