Spreadsheet or Database? What Building the Same Business Problem Twice Taught Me

The question I thought I was answering was whether a spreadsheet could run a real business. It took building the same system twice — once in Google Sheets, once as a full web application — to find out that wasn’t the question at all.

Both times, the underlying problem was identical: track what a tenant owes, when they paid, and what’s still outstanding. Same question, two completely different technical shapes. The distance between those two shapes is where I actually learned something — not either project on its own.

The bet I made with Rentify

Rentify started as a bet, not a prototype: most landlords don’t need a SaaS platform to manage rent and tenants. They need the simplest tool that does the job, built on something they already use. So Rentify isn’t an app. It’s Apps Script running behind three sheets — Transactions, Tenants, Ledger — and nothing else. Every sync clears the Ledger and rebuilds it from nothing. Payments apply to the oldest unpaid month first, waterfall-style, until either the payment or the debt runs out. No database, no server, nothing to host. Just a spreadsheet that recomputes itself correctly, every time.

Where the spreadsheet started to strain

The bet held up. It’s also where the honest limits live: no invoicing, no prorated rent for a tenant who moves in mid-month. Fixable, technically — but only by bolting more Apps Script onto a system that was never designed to hold much more than it already does. I didn’t feel that as a flaw so much as a boundary: a sign of where this tool’s job ends.

Starting over, on purpose

AA Properties came later, and it wasn’t a new problem. It was the same one, on purpose, in a different shape. I already had my answer to “can rent get tracked in a spreadsheet.” What I didn’t know yet was what changes when a real database, real authentication, and real permissions replace a spreadsheet standing in for all three. So I built a Next.js application — Prisma and PostgreSQL underneath, NextAuth handling login — with a working admin area for properties, tenants, leases, and invoices, wired together by actual relations instead of formulas. A property has tenants. A tenant has leases. A lease generates invoices. That’s a shape Sheets can approximate but never really hold.

The moment I expected to be about code

I expected the hard part of AA Properties to be technical — learning Prisma properly, wiring up auth, getting the relations right. It wasn’t. The hard part was answering the exact same questions I thought I’d already answered in Rentify: what actually makes someone an active tenant. What happens to a payment that arrives before a tenant’s official start date. Whether a partial payment covers the oldest unpaid month or the most recent one. Sheets had let me get away with fuzzy answers to all of that — a formula can quietly paper over an edge case for months. A real schema can’t. It forces you to write the fuzzy part down as an actual rule, in a language that doesn’t forgive ambiguity. That’s when I realized I hadn’t solved the business problem the first time. I’d only solved it well enough that the spreadsheet never made me admit otherwise.

What the unfinished parts were for

The second surprise was what the database was actually good for. I assumed the payoff would be speed, or scale, or just looking more serious than a spreadsheet. It wasn’t. The real payoff showed up in what I didn’t build. AA Properties’ schema also models maintenance requests, tenant notices, and expense tracking — features with no screen behind them yet, marked directly in the schema as later work. I hadn’t planned to leave them half-built. But once they existed as a shape the database could hold, I didn’t have to finish them to know where the system was going. A spreadsheet can’t do that. In Sheets, a feature either exists or it doesn’t — there’s no way to sketch tomorrow’s capability without building today’s. That’s the moment I stopped thinking of a database as “the powerful option” and started thinking of it as the option that lets you be honest about being unfinished.

Two shapes, not two tiers

It would be easy to read all this as “Sheets for prototypes, real apps for production.” That’s not what I actually learned. Sheets and a database-backed app aren’t sitting on a ladder, one above the other. They’re answering to different pressures entirely.

   Google Sheets                        Database-backed app
   (Rentify)                            (AA Properties)
   ─────────────                        ─────────────────
   speed                                 structure
   flexibility                           scale
   low cost                              permissions
   rapid iteration                       long-term maintainability

        Not "better." Built for a different stage
             of the same business problem.

Neither is the more serious way to solve a tenant ledger. They’re the right tool for different stages of the same problem, and the actual skill — the one I only found by building both — is knowing which stage you’re actually in. Not defaulting to whichever tool is more interesting to build in that week.

The part I still haven’t fixed

One thing didn’t improve the second time around: documentation lagged behind implementation on both projects, and it got worse, not better, with AA Properties. Rentify at least has a real technical spec — Apps Script pushes you toward writing things down as you go. AA Properties has more real, working surface area — more screens, more relations — and less written down about why any of it works the way it does. Building faster the second time didn’t come free. I just moved the cost somewhere I couldn’t see it as easily.

Neither project is finished, and I’m not presenting either one as if it were. They’re both still active — tools I keep learning from every time I scope something new. I’ve stopped asking whether a spreadsheet or a database is the right tool. The question that actually matters is what stage the problem is in, and how much structure that stage has actually earned. Build for the stage you’re in, not the stage you wish you were at.

Artifacts

• Documentation — Rentify’s CALCULATION_ENGINE.md, the technical specification referenced throughout this piece (private repository; not yet public).
• Source code — Rentify’s Apps Script implementation (Config.gs, Code.gs, Ledger.gs, Tenant.gs, Transaction.gs, Setup.gs, Utils.gs, Sidebar.html) and AA Properties’ Next.js/Prisma application, including prisma/schema.prisma (private repositories; not yet public).
• Lighthouse references — 03-projects/rentify/overview.md, 03-projects/aa-properties/overview.md (internal project notes, not public).