Claude Code can write an app fast. Getting that app a database, a login and a public URL is the part nobody warns you about.
So I built the same small app three times and timed each one. Here's how that went:
The short answer
If your app came out of Claude Code (or Cursor, ChatGPT or Claude chat) and now it needs a database, a login page and a public URL, you have three realistic options in 2026:
Floot (through its MCP server): the AI that wrote the app also sets up the database, the auth and the hosting, all from the same chat. Fastest for me by a wide margin: about 2 minutes from "create project" to a live URL.
Supabase + Vercel: the standard indie stack. Postgres with row-level security plus a CDN host. About 6 minutes for me, plus an email-code login on the hosting side.
Firebase (Firestore + Auth + Hosting): Google's all-in-one. About 7 minutes to get the database and auth ready, plus a CLI login to deploy.
Every option has a free tier, and I stayed on free tiers the whole time. None of them is wrong. Which one fits depends on how much backend you want to touch yourself.
What I actually built
I wanted something small that still needed all three pieces, so I built a shared guestbook:
you create an account with email and password
you post a note (280 characters max)
everyone sees every note, newest first
I built it three times. All three use the same features and the same rules: anyone can read, and only signed-in users can post as themselves. Then I timed each one from "nothing exists" to "a stranger can open a URL."
One caveat before the numbers. The timings are for me with an AI agent doing the typing. A person reading docs for the first time will be slower on all three, and slowest on whichever stack they've never seen.
Option 1: Floot, from inside the chat
Floot runs as an MCP server, so Claude Code (or Cursor, or Claude/ChatGPT chat) can call it as a set of tools. I never left the terminal. The whole thing was five steps:
create_project: "a tiny shared guestbook, email/password login, a shared list of messages."
provision_resource auth: this created a Postgres database, the user and session tables, password hashing, and login, register and password-reset pages. It seeded 19 files I didn't have to write.
execute_sql: one
CREATE TABLE messages (...). The typed schema regenerated by itself.Two endpoints (list and create) and one page, about 150 lines in total. The create endpoint checks the session on the server, so nobody can post as someone else.
publish_app: live at
guestbook-cc-test.floot.app.
Measured time: 1 minute 43 seconds from the first tool call to the live URL returning data.
What I liked: I never copied a key, set an environment variable or opened a second dashboard. The database, the auth secret and the hosting all came from the same place.
What to know going in:
You're building inside Floot's framework (React + TypeScript, serverless endpoints, typed items). If you already have a Next.js repo you love, it's not a drop-in host for that repo.
The "Made with Floot" badge is on by default. Removing it needs a paid plan.
Pricing, so nobody's surprised. When you build through Claude, ChatGPT or Cursor, your AI usage is billed by the plan you already pay for, so there's no second AI bill, and MCP builds spend no Floot AI credits. Floot does meter building actions per day. Pro is $25/month and includes $10/month of hosting usage; usage past that is billed.
Option 2: Supabase + Vercel
This is the stack most Claude Code tutorials point you to, and for good reason. Supabase gives you real Postgres with row-level security, and Vercel serves static files instantly.
Here's what I did:
Step 1. Created a free Supabase org and project. Supabase has a "Generate a password" button for the database password, so use it. The project was healthy in under a minute, which honestly impressed me.
Step 2. Pasted the schema and RLS policies into the SQL editor:
create table messages ( id bigint generated always as identity primary key, user_id uuid default auth.uid() references auth.users(id) on delete cascade, author_email text not null, body text not null check (char_length(body) between 1 and 280), created_at timestamptz not null default now() ); alter table messages enable row level security; create policy "anyone can read" on messages for select using (true); create policy "signed-in users insert their own" on messages for insert to authenticated with check (auth.uid() = user_id); Step 3. Copied the publishable key from Settings → API Keys into a config.js. This key is meant to be public. The secret key never goes in the browser.
Step 4. Wrote a ~40-line index.html with supabase-js from a CDN.
Step 5. Ran vercel deploy.
The database side was smooth. The hosting side is where I tripped.
vercel login opened a device-authorization page, and Vercel then asked to re-verify with a code sent to email. Once I entered the code, vercel deploy --prod put it live at https://supabase-vercel-six.vercel.app. One trap first: before logging in, the CLI fell back to an anonymous deployment with a 60-minute URL and a "claim" link, and claiming it gave a 404 DEPLOYMENT_NOT_FOUND on the permanent URL, because claiming doesn't promote a production deployment.
Measured time: about 6 minutes to a working app, plus the email-code login for a permanent URL.
To be fair to Vercel, that email code takes ten seconds. The bigger point is structural. You now have two dashboards, two sets of keys, and auth settings in one place with hosting settings in another. For a guestbook that's fine. By feature #12 it's a real cost.
Good fit if: you want raw Postgres, you like SQL, and you're happy to own the glue.
Option 3: Firebase (Firestore + Auth + Hosting)
Firebase gets the closest to "one vendor" without an MCP. Everything happens in one console:
Step 1. Created a project. I turned off Gemini and Google Analytics in the wizard because I didn't need them.
Step 2. Created a Firestore database (Standard edition, production mode = deny everything by default). One thing I didn't know: scheduled backups need the paid Blaze plan, and the wizard tells you so right there.
Step 3. Turned on the Email/Password sign-in provider.
Step 4. Replaced the deny-all rule with: anyone can read, and signed-in users can create a message only with their own uid, max 280 chars.
Step 5. Registered a web app to get the firebaseConfig object, and wrote a ~45-line index.html using the modular SDK from gstatic.
The database and auth were working (a public read through the REST API came back clean) after about 7 minutes.
Then hosting. Firebase Hosting has no upload button in the console, so you deploy with firebase deploy, which needs firebase login. I went through Google's consent screens without trouble. The last step of the remote-login flow asks you to paste an authorization code back into the terminal. One more trap: the CLI has to be logged into the same Google account that owns the Firebase project, or deploy fails with a 403. Once it was, firebase deploy shipped public/ to https://guestbook-cc-test.web.app.
Good fit if: you want realtime listeners (the list updates live with onSnapshot), you're fine with a NoSQL document model, and you might add mobile later.
Side by side
| Floot (MCP) | Supabase + Vercel | Firebase | |
|---|---|---|---|
| Time to a working app (my run) | 1m 43s, already live | ~6 min, then an email-code login to go live | ~7 min, then a CLI login to deploy |
| Dashboards touched | 0 (all in chat) | 2 | 1 |
| Keys I copied by hand | 0 | 1 (publishable) | 1 (web config) |
| Database | Postgres | Postgres + RLS | Firestore (NoSQL) |
| Who writes the access rules | Server-side endpoint code | You, in SQL | You, in rules language |
| Login wall I hit | none | email re-verify code | paste-back auth code |
| Free tier | yes | yes / yes | yes (Spark) |
So which one should you pick?
If you're building inside Claude Code, Cursor, ChatGPT or Claude chat and you don't want to set up a backend at all, Floot was the easiest of the three. The AI that wrote the app also provisioned the database, wired up the login and published it, and I never switched windows. That's the specific job it's built for.
If you want to own a Postgres database and you're comfortable in SQL, Supabase is excellent. The RLS policies are some of the clearest access control I've written, and pairing it with Vercel is the most documented path on the internet.
If you want realtime updates and a single Google console, Firebase is solid. Just plan for the CLI login and for backups being a paid-plan feature.
I'll admit I work on growth at Floot, so weigh my opinion on that one accordingly. That's exactly why I timed everything and kept the screenshots. Every step above is reproducible on a free tier tonight.
If you run the same test and get different numbers, I genuinely want to see them.
FAQ
Can Claude Code add a database and login by itself?
It can write the code for one, but something still has to create the database and store the secrets. With an MCP server like Floot's, Claude Code can do that provisioning itself. With Supabase or Firebase, you create the project in a dashboard and paste the keys in.
What's the fastest free way to host an app Claude Code wrote?
In my test, Floot through MCP: 1 minute 43 seconds to a live URL with a database and login. For a static frontend with no backend, vercel deploy is also near-instant once you're logged in.
Is the Supabase anon/publishable key safe in frontend code?
Yes, that's what it's for, as long as row-level security is on for every table. Never ship the secret/service-role key to the browser.
Do Firestore backups work on the free plan?
No. The Firestore setup wizard says scheduled backups need the pay-as-you-go Blaze plan.
Does building with Floot through Claude cost extra AI credits?
No. Through MCP, the AI runs on your existing Claude/ChatGPT/Cursor plan, so MCP builds spend no Floot AI credits. Floot meters daily building actions. Pro is $25/month and includes $10/month of hosting usage.





