Why Next.js + Supabase Instead of Just More PHP

Okay. The fight everyone's been asking about.

I'm faster in PHP. Let me say that plainly so nobody thinks this was a trendy decision. I can build in PHP without thinking. I know its weird corners, I know how it breaks, I've shipped real money through it. Choosing a new stack meant voluntarily becoming slower for a few weeks. You don't do that lightly. So I made myself actually argue it out instead of just chasing the shiny thing.

Here's the argument.

The problem I'm actually solving

The PHP version's real problem — I said it last post — is that it can't be signed up for. To fix that, I need real multi-tenancy: every host isolated, their own data, their own page, all on one shared system. And I need real authentication, because the whole product hinges on a booking flow where a guest can book and pay without making an account. That sounds simple. It is not. OTP verification, secure code storage, sessions, password resets, OAuth for the hosts who want calendar sync — that's a mountain of auth plumbing, and auth is exactly the kind of code where a small mistake becomes a security headline.

I could build all of that myself in PHP. I'd spend a month on plumbing before I wrote a single feature anyone cares about.

Enter Supabase

Enter Supabase. It's Postgres — a real, grown-up database — with authentication, storage, and row-level security built in, out of the box. The auth I was dreading? Mostly handled. The multi-tenant data isolation? It has a proper mechanism for it. And the free tier is generous enough that an early-stage, no-revenue product like mine doesn't pay a rupee to start. For a solo builder, that's not a convenience. That's the difference between launching and burning out on infrastructure nobody sees.

Then Next.js for the front

Then Next.js for the front. The pitch there is boring and that's why I picked it: one codebase for both the marketing site and the app. My landing page, my pricing page, my host dashboards, my public booking pages — all one project, one deploy. With PHP I'd be stitching together a few different things. With Next.js I push to one place and the whole product updates. When you're one person, fewer moving parts isn't a luxury, it's survival.

The real reason

So the real reason isn't "Next.js and Supabase are cool." The real reason is: they delete the most boring, dangerous work — auth, database management, hosting, deploys — so I can spend my limited hours on the part that's actually Book A Sloth. The booking flow. The money math. The two-minute promise.

That's my whole rule for picking tools now, and I'll give it to anyone who's choosing a stack:

What I didn't choose

What I explicitly didn't choose: a self-managed Postgres with some heavy ORM, or a separate single-page app talking to a separate API. Both are more "proper." Both are more control. Both would also have me building and babysitting infrastructure for weeks instead of shipping.

It's a bet. I'm slower today so I'm faster for years. Ask me in thirty days if I was right.

Tomorrow: the empty repo, the first commit, and the strange joy of a completely blank canvas.