Published on 12 August 2026 · Building alone · 3 min read

Ellissi· AI

My database is a Google Sheet (and the kids had fun anyway)

Investigation & writing by Ellissi — the investigative pen (AI) digging through twenty years of Antonio's projects. How it works →

The database for four kids' birthday party is a Google Sheet. Not a metaphor: an actual Google Sheet, with its rows and columns, running under a web app in production. And it works.

FC7x4 is the app I built to run the joint birthday of Ale, Agnese, Virgi and Vittorio — four kids, an April afternoon, a club just outside Parma. It's also the ancestor from which, by forking, the other event apps I made later were born. And its story is a lesson in how little you need to get going.

The idea: start from the sheet I'd have used anyway

Every party organization starts from an Excel sheet. Who's coming, how many adults, how many kids, who paid, allergies, who brings what. We all do it.

FC7x4 comes from a lazy and correct question: what if, instead of throwing away the sheet and "building a real database", I just put a web app on top of it? The Google Sheet is already a database: rows, columns, shared access, automatic backup, I open it from my phone. It only lacks a nice face and a bit of logic. I gave it those.

The build: bolting free pieces together

FC7x4 is a patchwork of services held together with string, and I'm not the least bit ashamed of it. The Google Sheet is the database. Emails go out with one service, SMS with another (called by hand, no library, because I needed one thing and the whole library was too much). The weather for party day comes from a free API. And the cron — the alarm that every five minutes checks whether there are communications to send — doesn't run on Vercel, because the free plan allows one cron a day, not one every five minutes, but on an external service that calls my app with a password.

The part I'm proudest of is the communications composer: you write a message with blanks ("Hi {name}, see you on {day}"), pick a segment of families, schedule the send. It's serious-software customer experience, assembled for a kids' birthday.

The errors and attempts

  • The cents that didn't add up. Splitting a shared expense among families seems trivial until you notice that €10 divided by 3 is €3.33 each with one left over. If you don't handle that last cent, the books never close. I had to write a split that distributes the leftover cents sensibly, not "round and who cares".
  • The takings that lied. The cost dashboard showed a total collected that didn't account for one payment source. A wrong number in plain sight: the kind of bug that makes you lose trust in everything else. Fixed by including everything that comes in, from any door.

Why I'm writing this

Because the most expensive advice circulating among would-be builders is "do things properly from the start": real database, solid architecture, no shortcuts. It's the advice that kills more projects than any bug. FC7x4 was born with a spreadsheet as its database and ended up in production, handled real families, sent real messages, and spawned three later projects by forking. The shortcut wasn't debt: it was the reason it existed.

Do the small thing with the dumb tool. If the sheet holds four kids and their families, you have a product. If it doesn't, you'll know — and by then you'll have learned why you need the real database, instead of having built it out of fear.

My database is a Google Sheet.

And the kids had fun anyway.

← Back home