VisiCalc was the original killer app, followed by Lotus 1-2-3. Then Microsoft Excel compelled millions of American and European tinkerers to purchase PC's as well as spend $1,000's on accessories such as tape drives, dot-matrix printers, even voice synthesizers/audio digitizers. People ran their businesses, did their taxes, published zines and managed subscriber lists in spreadsheets.

Three major changes since then:

cloud vs personal: enables native collaboration
mobile vs desktop: enables native accessibility
zero cost software: enables native access

"Zero cost" is actually a barbell, with Apple/Google/Microsoft/Meta/Amazon on one side and Linux/open source/self hosting on the other. Neither is free as in free beer. But zero cost naturally pushes back against the ubiquity of paid AI service providers.

The cutting-edge Excel equivalent today looks something like: orchestration in Google Sheets; ChatGPT / Gemini / DeepSeek for doing things in a parallel space, with a human combining things in meatspace; Zapier/Jotform to stitch services together; Figma/Canva/Airtable/email attachments (?) for collaboration.

I'm a continuity guy, as well as a believe-what-companies-promise guy, and have stuck with Excel ever since paying for my first "lifetime" license over 20 years ago. This guy put it best:

quote

spreadsheets are the first and most widely used NoCode platform in the world

My Life with Excel

I can't even think about Excel, without writing a full post-within-a-post. You may read my memory-lane drivel below, or skip it altogether without loss of generality.

I Love You Excel Truly, Madly, Deeply

1. Formative career experiences

my second year working in finance, I met my great friend Mike D who was not a coder but spent a couple of personal weekends reading the VBA For Dummies book. Very Smart People Can Just Learn Things!

This was a huge career unlock for him, if only (but not only!) as a way to communicate effectively with his managers via unique Excel chart analysis pasted into PowerPoints.

the concept was totally new and unimaginable to me. I had assumed Excel was babywork. My own first year in finance was all about writing perl scripts for trade reconciliation, as we had voice outcry and manual trade entry including transcription from hand-written blotters. I took over management of our trading desk's "distributed trade order entry system". That is, I walked up and down the aisle every 2 hours, looking for two clipboards, one wooden one plastic, on which traders jotted their trades. One dude Melch did so many trades he wrote them down on yellow stickies because other traders wrote too slowly on official pads.

Perl helped me aggregate exported data after trade entry, presented it in various cleaned up ways, and build a test suite of commonly repeated human mistakes that could be caught upstream of risk reporting.

my second year in finance was all about perl scripts maintaining data for Splus and kdb, plus creating unique Excel chart analyses pasted into PowerPoints.

I also became great friends with Murphy, who had made his own Excel addin that he freely shared with the team. It included hotlinks to the quant library docs wiki, and critical keyboard shortcuts such as "Expand array function to fill the actual shape of the data".

my third year in finance was about building and using a greenfields OMS/TMS/live risk engine/reports platform with Excel as frontend. We told our boss the project's name CTM stood for Citi Trade Management, but actually we picked the letters to spell Chicken Tikka Masala.
my eighth year in finance, I worked with W, a recent MIT grad. Instead of trying to join the team trading the most intellectually challenging products, he fought to join the biggest and most profitable business, one that was dominated by meatheads and poker players. W built for them a faster and customizable-in-just-the-right-ways VBA-based options quick pricer, which ran circles around the official company-approved system of record. He moved to a tech startup incubator shortly after bonuses were paid that year.

2. Excel 🤝 ODBC 🤝 Sqlite

one of my treasures, which followed me from job to job, was a slightly contraband (we weren't allowed to install external software) Sqlite ODBC driver which allowed Excel to talk to Sqlite files on network drives.
I could write queries instead of doing crazy lookups, and maintain data independently of the analysis site. I evangelized this to everyone, but surprisingly got zero interest from anyone else in front office. Everyone knew, you don't get a higher bonus by owning your own data. You get it by politicking to convince your boss that your business needs to fight to spend internal IT budget on valuable data.

3. VBA Add-in innovations

I owned and shipped an Excel add-in for many years and multiple generations, which (ahem) provided ☝️ hotlinks to documentation, and critical keyboard shortcuts for common calculations☝️.
We had a global team, where everybody had at least a master's in finance, and collectively could not agree on return calculations!

Most people calculated price return, but some used log calculations to enable easier compounding calcs.

Most people looked up the start date of the period by using a VLOOKUP, or a BLP function to find the first closing price in an interval, rather than finding the first observation in the window and going one observation back (which is not as simple as subtracting one day, due to weekends and holidays).

We annualized returns inconsistently: 360/365 BDC, 252/253/actual trading days, and 365.25/actual calendar days. WTF.

We had libraries to handle everything, but sometimes you just need a quick and dirty answer.

Or, you need a portable spreadsheet that people outside of your team can operate, even if they don't have permissions to the library.

Or, the boss's boss never bothered to install the add-in (he had permissions!), and wanted to "poke around the data" with a useful junior as a guide, so he could discover people with skill in "thinking from first principles" without making their eyes glaze over with "unnecessary details".

It's trivial to calculate the simple (but slightly wrong) answer. The correct calculation is complicated, with edge cases and sharp edges including questions of convention (and ego!).

Different use cases could require different "precision" and effort and time. And of course, organizational reuse of context-free numbers can lead to embarrassing, avoidable situations. E.g., the boss verbally relaying to a client that the annual returns are 8.6%, when our published material shows 8.2%.

Excel with VBA add-ins enabled a tech solution -- an instantaneous and always-accessible menu item -- to solve our organizational and interpersonal coordination issues.

Excel is the Living Dead

Excel costs money; Google Sheets is free

Despite free educational licenses, students mostly use Google due to:

less of a walled-garden integration ecosystem
distrust they will get a future employer who will pay for Office, so just learn Sheets' powerful cloud functions
optimism that everyone can learn Excel. It's easy, so just cross that bridge when it comes

For similar reasons, new organizations do not use Excel. The Man uses Excel. Excel is a suit and tie; Sheets is business casual; Numbers on your phone is flip-flops and shorts. OpenOffice/LibreOffice is a hand-woven shawl and hippie beads. Zoho Office is a linen suit and getting drinks from a chai-walla rather than a Nespresso machine.

In the productivity parts of the Office Suite, innovation has paused entirely. Word, Excel, and PowerPoint are long in the tooth. Corporate dynamics send talented engineers to work on new products. The product owners are no longer strategy-setting generals, they are captains of soldiers sitting on the walls.

No more ownership models

Everything is a subscription, maybe tied to your face via Windows Hello. The free version is only Microsoft Excel for the Web, which is mostly crippled for mobile / tablet / Chromebook use. Critically, no VBA and therefore the only extensions are add-ins downloaded through a Store. (Some are free! More below.)

AI may disrupt this. Soon. Eventually. But not yet. For Microsoft, AI will most likely disrupt Office after it unlocks the dev space and the consumer space for them.

These Are Not the New Excels You Are Looking For

It is actually too early to tell, but I can have opinions

AirTable launched in 2013. I have used it, lightly but continuously, for over a decade. I hesitated to move critical workflows there, and it never seemed compellingly better than alternatives. AirTable has relaunched in 2025 as an AI app.

NocoDB has 57k Github stars and millions of users. Grist has 8.9k stars. Rowy has 6.7K stars. Baserow has 2.8k stars. I spent a few hours installing NocoDB and Grist to play with their self-hosted versions. Both were super easy to get going on cheap hardware, which was a great sign.

NocoDB felt sluggish and bloated, like how GIMP feels after coming from Photoshop. Since I'm not sold on AirTable after a dozen years (neither are they, apparently, as they pivoted to AI), I'm not able to commit. Just as photo editing migrated to specialized low-cost phone apps, I don't see NocoDB as the future of interacting with tabular data.

Grist feels modern and snappy, like a new paradigm of how to think about data. Definitely putting this on my list of projects to monitor. I browsed their Github Issues, went to their active Discord, and saw the nature of situations that users are exploring. Am definitely coming back to this later! It probably has too much surface area/ambition as a SaaS. But it's been around for almost as long as AirTable. Kudos to their dedication to private data for the world, as well as their ability to deliver modern-feeling FOSS software over this project's long-ish lifespan.

Python for Excel, Power Pivot, Power Query, and Office Scripts are Microsoft's efforts at allowing you to pay more for features that were once included for free. No shade, but these are products designed for CTOs and corporate purchasing managers, not for engineers, explorers, problem solvers, and solutions-oriented business people.

A Painful Admission

xlwings has been my side piece for over a decade. It's a Python library for Excel and Google Sheets, including xlwings Lite, a free add-in that works in the free cloud version of Excel. I've also messed around with xlrd, XlsxWriter, and of course, that old cross-dressing hag See Ess Vee.

xlwings Lite checks all the boxes:

TRIGGER WARNING: OPINIONS ARE LIKE ***HOLES 👇

As soon as I started trying to do stuff, I quickly remembered why in Python I always preferred to mess with xlrd. Using xlwings feels like building flat-pack furniture with an oversized 6-in-1 pocket knife, rather than a screwdriver and Allen wrench.

xlwings is admirably cross-platform and gives you access to the full power of Python rather than a subset. But by relying on generalized rails, the pathways I build feel like I'm making Lego Harry Potter using rectangular blocks and yellow-headed people, not working with an expensive, fully-licensed Harry Potter Lego set.

In return for power, freedom, and zero cost, I'm willing to accept a 2x ~ 5x hit in performance, efficiency and productivity. But compared with legacy Excel + VBA, xlwings in Excel for web feels like a 10x ~ 20x slowdown, including the learning curve.

Real Talk

As a a guy who's worked professionally on databases since the early 90s, I used to have tremendous grit and pain tolerance. I could spend weeks wrasslin' VBA and ODBC connectors, and enjoy the thrill of discovering unlocks hinted at by Stack Overflow false starts and technical cul-de-sacs.

I don't wanna play with you any more

In August 2025, free untraceable DeepSeek chat plus a $20/month Cursor subscription makes it too painful to code in a web browser-embedded pyodide environment. Life's too short to spend brain cycles on weird, idiosyncratic syntax, or to iterate in a REPL. We have HMR and magic auto-complete now.

The Forever Stack

Cobbled together over ~3 days

mostly vanilla Sqlite3 (have had this for ~15 years)
- 100% normalized tables - this is very Lindy
- primary keys, but no foreign key constraints enforced by the database. only enforced by usage convention. This future-proofs modularity. (I guess I could just remove foreign keys as needed, but that's too much of a mental hurdle. I handle data hyper carefully anyway.)
- unique id's, but not auto-generated. Again, this forces future-proof portability, and is a lesson learned the hard way, from migrating from Sybase to SQL Server to Sqlite to DuckDB
- in-database views rather than JOINs in queries stored outside of the database
- only the most permissive, generalized data types enforced by the database. Only usage convention enforces things like rounding/numerical precision. This is another hard-won lesson from migrating across databases that make different assumptions about data integrity
- Sqlite is more useful as lowest common denominator, than JSON files. Note that Booleans need surprisingly careful thought. I migrated to a NULLABLE INTEGER column to force me to remember that for the future
- only one CTE (so far!). Yesterday I learned that Sqlite has had CTE support since September 2018. I had gotten away with smart views optimization all this time, but 7 years is long enough to live without window functions
- only one TRIGGER, also introduced yesterday, specifically for an edge case of atomic multiple INSERTs across a network connection
sqlite-rest, a light-weight FOSS REST API server by hbc, written in Go
- this replaces my Sqlite ODBC driver, which I had used since Windows 95. Which still has 32-bit/64-bit quirks!
- the REST server is NOT battle-hardened, but you can simply read the code as it's so simple. Talk to me about JWT security if you care! There are some mildly unexpected consequences of the implementation (I think they're OK if you know what you are doing)
shell scripts to backup to S3
- one to pull, one to push, plus a cron job. Each one is disposable and easily replaced
- Claude and DeepSeek write better bash scripts than any lazy programmer not writing for professional uses. You generally get for free: error handling, clear user updates, internal logical flow rather than a lazy sledgehammer, and parameterization. You may or may not get security (hit or miss), and on request you may get overconfident re-implementations of protocols using outdated APIs. Don't ask me how I know.
- I chose not to do WAL and replication/sync at this time. Have investigated deeply LiteStream, ElectricSQL, and Evolu. Maybe in the future. Or maybe will use pglite in wasm instead. Right tool for the right job.
SPA React app
- a separate client-side route gives access to each distinct database view
- TanStack React Query + TanStack Table provide easy client-side sort/filter, as well as easy-ish mutations
- client-side React lets me enhance static data with live data, such as ticking market prices
- thin Hono backend to do OAuth and reverse proxy the REST API
Streamlit app for more involved data analysis. DuckDB imports the Sqlite data directly and provides columnar execution performance
Cloudflare Zero Trust Tunnel, rather than securing nginx or Caddy myself. Neither are rocket science, but I get forever vigilance for free.
my old Excel spreadsheets continue to connect to local Sqlite via ODBC. The data will outlive the Excel interface
cloud Excel and Google Sheets can talk to data via REST. I continue to explore security models for handling secrets in those environments
stateless OAuth gives me 2FA/MFA for free, including password-less passkey protection. I chose web2 OAuth over web3 solutions due to availability and UX. Everyone has a Google account they can connect to a website, but not necessarily an Ethereum wallet. While the paid, managed Web3 solutions are quite slick (I really like thirdweb Connect, Privy and Dynamic), the non-managed experiences remain accessible only to crypto enthusiasts.

Ongoing Cost-to-Operate

Compute is 1/ a tiny Go binary for the REST API wrapper around Sqlite, 2/ Streamlit on Python, and 3/ serverless Workers to provide auth and a reverse proxy. I can serve this on the cheapest VPS configuration, a Raspberry Pi, or Brooklyn dumpster-level free hardware.

Data is <100 MB. I don't need performance or throughput, and could even self-host with MinIO. But why, when there are multiple S3-compatible providers competing to give multiples of that for free.

The data requirement is so light that I am crazily dreaming about adding video and AI-assisted OCR for documents.

Networking + bandwidth requirements are de minimis also. No more than a personal static website with a blog. Cloudflare is happy to provide this for free, in return for bringing more web traffic onto their network.

Some AI resources were required to build the new stack. It might have taken me two weeks~a month without AI help, and 3 days with help. Probably zero ongoing AI assistance required to maintain the code.

I actually anticipate the ongoing Gold Rush for AI applications will see infrastructure free plan allocations continue to get higher, not lower, while the pricing squeeze will eventually come to AI compute rather than storage + compute + networking.

tl;dr

I just migrated 20 years of personal data.

It was in Excel + VBA + local Sqlite, all versioned manually.

Now it lives in Sqlite in S3 + REST + SPA + Streamlit + bash scripts + Excel.

It took about 3 days to a week of all-in work, including repurposing existing pieces + templates. The entirety of the new stack is friendly to AI-assisted development, except maybe the tiny REST glue layer which you just have to spend 10 minutes to figure out.

The old stack was free-to-run, because I had paid to own Excel in the past.

The new stack is forever free. It's built on FOSS and light-weight enough to run for less than a NYC breakfast burrito.

Excel is Dead : as the primary method to reason about data, with Sqlite as a service to offload certain calculations closer to the data,

Long Live Excel : as a legacy backup widespread accessibility layer, akin to interactive PDFs !