The First Production Stack — Domains, Auth, Data, Logs, and Payments

"I have an AI-built demo and I want to understand the path to production.
Do not write code yet.
Product context:
- what the app does: [describe it]
- who will use it first: [describe first testers]
- current stack: [list tools if known]

The first production question is not "Can the AI deploy it?"

The first production question is:

What has to be true before another person can trust this thing with their time, account, data, or money?

That question changes the stack. A demo can live in a browser builder. A production product needs boring, dependable operating parts.

The table-stakes stack

For a modern AI-built web product, these pieces are not luxury add-ons. They are the baseline:

| Layer | What it does | Good first choices | Why it matters | |---|---|---|---| | Domain and registrar | Owns the name people type and the place DNS starts | Cloudflare Registrar, Porkbun, Namecheap | If you cannot control the domain cleanly, you do not really control the product surface | | DNS provider | Routes the domain to the right services | Cloudflare, ClouDNS, DNSimple | API support, DNSSEC, fast propagation, and reliable records make production changes safer | | Hosting and deploys | Runs the app and creates preview/production environments | Vercel for Next.js, Netlify for simpler web apps, Render/Fly/Railway for services | You need repeatable deploys, previews, rollbacks, logs, and environment variables | | Database | Stores real product data | Supabase Postgres, Neon, PlanetScale where it fits | The database is the business memory, so backups, migrations, access rules, and row-level security matter early | | User management | Handles sign-up, sign-in, sessions, roles, and organizations | Clerk, Auth0, Supabase Auth | Auth is too risky to casually invent; use a provider and configure it deliberately | | Payments and subscriptions | Turns usage into revenue and entitlement | Stripe Checkout, Billing, Customer Portal | Subscriptions need receipts, tax posture, webhooks, cancellation paths, and entitlement state | | Source control | Tracks every change and lets you recover | GitHub | Pull requests, issues, Actions, Dependabot, and audit history are part of production control | | Observability | Shows what broke and who was affected | Sentry, Vercel logs, structured app logs | If you cannot see errors, performance, and release history, users become your monitoring system | | Agent memory | Preserves decisions across AI sessions | AGENTS.md, CLAUDE.md, Obsidian, project notes | Agents get better when the project has durable instructions, decisions, and known boundaries | | Security sweeps | Keeps drift from becoming a breach | dependency audits, secret scans, auth reviews, RLS checks, permission reviews | Production is a moving target; security needs routine, not one big cleanup before launch |

You can swap vendors. You cannot skip the layers.

DNS and registrar quality matters more than beginners think

Most first-time builders treat the domain as a checkout chore: buy the name, paste a record, move on.

That is too shallow.

Your registrar and DNS provider affect:

• how quickly you can point previews, staging, and production at the right place
• whether you can automate DNS changes through an API
• whether you can enable DNSSEC and protect against spoofing
• whether email records are set correctly
• whether a future migration becomes a clean change or a painful lock-in problem

For most new builders, Cloudflare is the safest default because registrar, DNS, proxy, SSL, DNSSEC, API access, and security controls live in one strong platform. ClouDNS is worth knowing when you want DNS-first management, many domains, or built-in DNS failover. DNSimple and Porkbun are also worth considering when clean registrar/API ergonomics matter.

Do not pick a registrar only because it was $2 cheaper. Your domain is part of production infrastructure.

Vercel, Supabase, Clerk, Stripe, Sentry, GitHub

A very practical first production stack looks like this:

• Vercel for the Next.js app, preview deployments, production deployment, environment variables, and rollback.
• Supabase for Postgres, row-level security, storage where needed, and operational database visibility.
• Clerk for passwordless sign-in, OAuth, sessions, user profiles, and organization membership.
• Stripe for subscriptions, invoices, payment method handling, coupons, trials, and the customer portal.
• Sentry for errors, release tracking, source maps, performance signals, and enough context to debug production failures.
• GitHub for source control, issues, pull requests, dependency updates, CI, and deployment history.
• Obsidian or another durable notes system for project decisions, agent instructions, customer feedback, launch checklists, and postmortems.

This is not the only stack. It is a strong default because each tool owns a clean boundary and has enough API support that agents can help manage the product without turning the project into a pile of manual clicks.

The first production checklist

Before you ask an AI agent to "take this to production," make it answer these questions:

• What domain will users see, and where is DNS managed?
• Which environment is production, and which environment is preview or staging?
• Where do secrets live, and how are they rotated?
• What database stores real data, and what tables have access policies?
• How do users sign in, and what roles or tiers can they have?
• What Stripe state grants access: trial, active subscription, coupon, comped account, or manual entitlement?
• What happens when a payment webhook fails?
• Where do errors go, and who sees them?
• How do you roll back the last bad deploy?
• What GitHub branch, pull request, or commit represents the current live version?
• What security sweep runs before a wider invite?
• Where are the durable decisions written so the next agent session does not forget them?

If the agent cannot answer those, it is not ready to ship. It is ready to help you build the checklist.

Why subscriptions can be valuable

Software subscriptions are valued differently from one-time services because recurring revenue creates a clearer picture of future cash flow.

A buyer, investor, or operator usually cares about:

• recurring revenue: are customers paying again next month?
• retention: do customers keep using it after the first excitement wears off?
• gross margin: does revenue scale faster than support and infrastructure cost?
• distribution: can you reach buyers without paying too much for every customer?
• workflow depth: is the software embedded in something customers do repeatedly?
• data and trust: does the product become more useful because it understands the customer's operation?

AI does not automatically make a software company valuable. A model can make the build cheaper and faster, but valuation still follows demand, retention, margin, distribution, and operational credibility.

That is why "AI software" by itself is weak positioning. "A recurring software product attached to a real workflow and a real customer channel" is much stronger.

How commerce can help software

If you already have a commerce business, it can become the wedge for a software product.

Take a specialized sales business such as peptide, supplement, lab-supply, wellness, or B2B product sales. The sales channel can help a software product because it already has:

• real customers asking repeated operational questions
• support threads that reveal what people do not understand
• order, fulfillment, compliance, and communication workflows that can become software features
• an audience that can test whether the tool saves time or reduces mistakes
• trust that a cold software startup does not have yet
• revenue that can fund product experiments before the software stands alone

That does not mean the commerce business and software product should be mixed carelessly. If the underlying product category is sensitive, regulated, or reputation-heavy, the software must be even more careful about claims, privacy, audit logs, and support boundaries.

The strategic point is simple: sales can validate pain. Software can turn repeated pain into recurring value. AI can shorten the build loop. The business still has to prove people come back.

Prompt to give your agent

"I have an AI-built demo and I want to understand the path to production. Do not write code yet.

Product context:

• what the app does: [describe it]
• who will use it first: [describe first testers]
• current stack: [list tools if known]
• business model: [free, subscription, internal, commerce-backed, not sure]

Please produce:

1. the missing production stack checklist across domain, DNS, hosting, database, auth, payments, logs, GitHub, notes, and security
2. the safest recommended vendors for each missing layer, prioritizing strong APIs and clean handoffs to agents
3. the smallest production milestone I should target before inviting more than three testers
4. the subscription or entitlement model I should use if early testers are free but need full paid access
5. the business-value hypothesis: why this could become recurring software revenue, what would prove retention, and how any existing sales channel could help validate it

Be practical and skeptical. Separate table stakes from nice-to-have features."

What you must review yourself

• Whether the domain, DNS, database, auth, payment, logging, and GitHub boundaries are real or only assumed.
• Whether the subscription model grants access through a reliable entitlement state instead of a hidden manual hack.
• Whether your existing business channel is validating software demand or merely giving you an audience.
• Whether sensitive commerce, customer, health, payment, or identity data is being handled with appropriate caution.
• Whether security sweeps are scheduled as a recurring habit, not saved for launch week.

Common mistakes to avoid

• Treating deploy as production. A public URL is not the same as a reliable product.
• Buying a domain from a cheap registrar with weak DNS/API support. Domain control is production control.
• Letting the AI invent auth or billing. Use mature providers and configure the entitlement boundary clearly.
• Skipping Sentry or logs until after users complain. Production needs visibility before the first invite.
• Confusing initial curiosity with subscription value. Value shows up when people return, pay, and depend on the workflow.
• Ignoring security drift. Every dependency, OAuth app, API key, DNS record, and database policy can age into risk.

Key takeaways

• Production starts with operating layers: domain, DNS, hosting, database, auth, payments, source control, observability, memory, and security.
• Good DNS and registrar API support are table stakes for serious products.
• Vercel, Supabase, Clerk, Stripe, Sentry, GitHub, and Obsidian form a practical first production baseline for many AI-built web apps.
• Subscription value comes from recurring demand, retention, margin, distribution, and workflow depth, not from the fact that AI helped build the product.
• Existing commerce sales can validate pain, fund experiments, and create distribution, but sensitive categories require stronger claims, privacy, and audit discipline.

What's next

Now you have the first production stack map. The deeper Guild paths show each layer in detail: source control, security essentials, first project deployment, real-product operations, DNS, databases, identity, monitoring, and agent orchestration.