Do I need a separate auth provider for my first app?

No. Use the auth that comes with your database, such as Supabase Auth. A dedicated provider like Clerk or WorkOS is worth it once you need organisations, SSO or enterprise compliance, and migrating to one later is straightforward because you are moving users, not rewriting the app.

What does a first vibe-coded app cost per month?

On free tiers, roughly the cost of a domain, about ten to fifteen dollars a year at the time of writing. Once you cross into paid tiers, budget twenty to twenty five dollars per service per month, so a three service app is around sixty five dollars a month before usage.

Should I let my coding agent pick the services?

Pick them yourself and tell the agent. Agents optimise for a complete-looking scaffold and will add analytics, queues, feature flags and payments that you then own forever. Give it the four services you chose and it will wire them up well.

What services do I need for my first vibe-coded app?

July 15, 2026 · The Squiid team · 6 min read

Short answer: hosting, a database, a way to send email, and a domain. That is the whole list for most first apps. Auth normally arrives attached to the database, so it is not a separate decision yet. Everything else, payments, SMS, analytics, background jobs, a vector store, a CDN you configured by hand, is a later problem, and adding it in week one is the most reliable way to stall a project that was otherwise about to ship.

This matters because a coding agent will happily wire up nine services if you let it. Ask Claude Code or Cursor for "a SaaS starter" and you get Stripe, an analytics SDK, a queue, a feature flag service and an error tracker before a single user exists. Each one is an account, a key, a dashboard and eventually a bill. None of them makes the app work.

Hosting: somewhere the app actually lives

You need a URL other people can open. For an AI-coded app that almost always means a platform that takes a Git repository and gives you a deployed site with HTTPS, preview URLs per branch and environment variables in a settings page. Vercel, Netlify, Cloudflare, Railway and Render all do this. Pick the one your framework's docs assume, because your agent has read those docs and will write configuration that matches.

What to actually do: connect the repository, set the environment variables in the dashboard rather than committing them, and deploy on every push to main. Do not set up a custom CI pipeline yet. Do not containerise anything yet. If your app is a Next.js or Vite project, the default settings are correct and the agent should not be touching the build command.

The one thing worth checking on day one is what happens when traffic spikes. Read the page that explains what the free tier cuts off at and whether exceeding it pauses the site or bills you. Those two behaviours are very different when a link gets shared.

A database, which is also your auth

Almost every app needs to store something and know who is asking. The efficient move for a first project is to pick a database that also ships auth, file storage and a realtime channel, because that is one account instead of four. Supabase is the common answer: it is Postgres, so nothing you build is a dead end, and it bundles sign-in, uploads and row level security in the same project.

Postgres matters more than it sounds. Coding agents write good SQL because there are decades of it in public repositories. Hand an agent an unusual query language and you will spend your evening reviewing confident, wrong code. Schema written against Postgres also moves to any other Postgres later, which is the closest thing to an exit you get at this stage.

Say no to a separate auth provider for now. Clerk, Auth0, WorkOS and Stytch are all better than what your database bundles, in ways that start to matter when you have organisations, SSO customers or compliance requirements. On a first app they add a second identity system to keep in sync with your user table, which is a genuinely annoying migration to do backwards.

Email, because every app sends some

Sign-in links, password resets, receipts, an alert to yourself when something breaks. You need a transactional email API, and you need it earlier than you expect. Resend, Postmark and Mailgun all work. The code is a single POST request and your agent will write it correctly first try.

The part that is not code, and the part that goes wrong, is domain authentication. You add SPF, DKIM and DMARC records at your DNS provider, ideally on a dedicated sending subdomain such as mail.yourapp.com, and you verify it before you launch. Email that lands in spam does not throw an error, so nothing in your logs will tell you the password reset never arrived. Test by sending to a Gmail address, a work address and an Outlook address before you ship.

A domain, and almost nothing else

Buy the domain, point it at your host, enable HTTPS, done. Cheap and permanent. The temptation here is to also set up a CDN, an edge cache, image optimisation and a status page. Your host already does the first three by default, and you do not need the fourth until someone else depends on your app being up.

What you can safely skip

Payments. Add Stripe the week someone asks to pay you, not before. Payment code is easy; tax, invoicing and webhook reconciliation are not, and they are wasted effort until there is revenue.
SMS. Twilio is excellent and US A2P registration takes days and paperwork. Use email for verification codes until you have a reason not to.
A vector database. Postgres with the pgvector extension handles far more rows than a first app will ever have. A dedicated vector service is a scaling decision, not a starting one.
A queue or workflow engine. A cron job on your host covers scheduled work. Reach for Inngest or Trigger.dev when you have a job that genuinely must survive a deploy.
Analytics and error tracking. Worth adding, but in week two, and one of each. Two analytics tools is a sign the agent picked and you did not.

What this costs before anyone visits

At the time of writing, a first app on free tiers costs about the price of the domain. Hosting has a free tier for personal projects. Supabase has a free project. Resend has a free sending allowance. You will pay roughly ten to fifteen dollars a year for the domain and nothing else until you outgrow something.

The step after free is the one to plan for. Paid tiers tend to start around twenty to twenty five dollars per service per month, and you usually cross into them for a boring reason: a free database pauses after a week of inactivity, or the free email allowance is per day rather than per month. Three services on paid tiers is roughly sixty five dollars a month before a single unit of usage, which is the number that surprises people.

A setup order that works

Create the repository and get an empty page deployed. Prove the deploy pipeline before there is anything to debug.
Create the database project. Put its keys in your host's environment variables and in a local .env that is listed in .gitignore.
Build one real feature end to end with sign-in. Not three half features.
Add email and verify the domain. Send yourself a test from production.
Point the domain at it and share the link.

Give your agent this order explicitly. Left alone, agents build breadth: five pages, no persistence, no auth. Telling it to make one path work end to end, including the boring parts, produces something you can actually show.

The part the demos never show

Four services means four sign-ups, four passwords, four sets of API keys, four dashboards and eventually four line items on your card statement from four different merchants. None of that is technically difficult and all of it is friction, especially the keys. They end up in a local .env, in the host's settings page, in a preview environment, in a chat window where you pasted an error, and occasionally in the repository. When one leaks you have to work out which of the five copies to change.

That is the problem Squiid exists for. One account provisions the services, holds the upstream keys and gives your project a single SQUIID_API_KEY, so the database, email and hosting all arrive on one invoice with prepaid credits spent at the provider's own list price. It does not make the list of services shorter. It makes the list of accounts, keys and bills exactly one long, which on a first app is most of the pain. If you would rather not, the advice above stands on its own: four services, in that order, and nothing else until someone asks for it.