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 I decided 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.

Why a ground-up rebuild

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

I’d been aware of Conflict-free Replicated Data Types (CRDTs) for a while from collaborative apps like Linear and Figma, but it was working through this that made me realize they were exactly the primitive I needed. Each replica edits independently and merges later without a central authority, which is the property required for offline-first editing, branching, and real conflict resolution. The research in this space has gotten a lot more active recently, and I landed on Automerge, a Rust-based general purpose CRDT library, to build on top of.

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.