Our recommendation, up front. We make Proxy Mail QA, and almost nothing in this list is ours. We recommend Proxy Mail QA for one slot only: if your website has sign-up, log-in or password reset, or sends account emails such as invites, it gives you test inboxes to check those emails work. If your site has no accounts and sends no email, you don’t need it, and the rest of this guide still applies.
The list
| You need | What it’s for | Common choices |
|---|---|---|
| Somewhere to write or generate the code | Building the site | An editor such as VS Code or Qoder IDE; an AI coding agent such as Qoder, Claude Code or Cursor; or, with no code, a builder such as Webflow, Framer, Squarespace or WordPress |
| Version control | Undoing mistakes, working with others, deploying | Git, with GitHub or GitLab |
| A framework (optional) | Pages, routing and data without starting from nothing | Next.js, Astro, SvelteKit, Nuxt |
| Hosting | Putting the site on the internet, with a preview for each change | Vercel, Netlify, Cloudflare Pages, Render |
| A domain name | Your own address, and the sending domain for email | Any registrar; DNS at the registrar or Cloudflare |
| Sign-up and log-in (if people have accounts) | Accounts, passwords, codes and magic links | Supabase Auth, Clerk, Firebase Authentication, Auth0, Auth.js, Better Auth |
| A database (if it stores anything) | Accounts, orders, content | Postgres (Supabase, Neon), Firestore, SQLite |
| An email provider (if it sends email) | Verification, reset and receipt emails, from your domain | Resend, Postmark, Amazon SES, SendGrid, Mailgun |
| Payments (if it sells) | Cards, subscriptions, invoices | Stripe, Paddle, Lemon Squeezy |
| Analytics | Knowing what people use | Plausible, PostHog, Google Analytics |
| Error tracking | Knowing what broke, before users tell you | Sentry |
| Tests | Knowing a change didn’t break sign-up or checkout | Playwright or Cypress for the browser; Vitest or Jest for code; Proxy Mail QA for the emails |
| Checking tools | Speed, accessibility, links, SEO | Lighthouse, axe DevTools, a link checker, Google Search Console. More in tools to help build and check my website |
| Legal pages | Privacy policy, terms, cookie notice where needed | Written for your site and where your users are |
What you can skip
- A site with no accounts (a portfolio, a café, a landing page): a builder or a framework, hosting, a domain and analytics. A form service if you want messages. No auth, no database, no email testing.
- A shop: a hosted shop platform such as Shopify may cover hosting, payments, accounts and email in one, and you test what it lets you change.
- An app with accounts (a SaaS product, a community, a booking site): most of the list. The parts most often missed are the email provider’s set-up and testing the emails.
Where Proxy Mail QA fits
Once people can sign up, your site sends email that has to work: the verification code or link, the password reset, the invite. Those break in ways other tests don’t catch. A link points to localhost, the provider is still in sandbox mode and sends nothing, or two emails go out instead of one.
Proxy Mail QA gives you a new private test address for each try, pulls out the code or link, and checks how the email was sent. You can use it by hand in the browser with Proxy Mail QA for Chrome, in Playwright or Cypress tests with its npm package, or from an AI agent such as Qoder’s through its MCP server. The free plan covers 500 test addresses in total.
It doesn’t build, host or design anything, and it doesn’t send email for your site: you still need an email provider.
A first stack for an app with accounts
One way to put it together, if you’re building with Qoder:
- Code: Qoder’s agent, in a Git repository on GitHub.
- Framework and hosting: Next.js on Vercel, with a preview deployment for every branch.
- Accounts and data: Supabase, for sign-up, log-in and the database.
- Email: Resend, sending from your own domain. Supabase’s built-in email only sends to your own team, a few an hour, so set up your own email provider before anyone else signs up.
- Errors: Sentry.
- Tests: Playwright for the sign-up flow, with Proxy Mail QA for the verification email, run on each preview deployment.
Any row can be swapped for another from the table. The order matters more than the brands.
The order to set things up
- Buy the domain early. Email providers need it to send from your name, and the DNS records for SPF, DKIM and DMARC can take a while to be picked up.
- Set up the repository and hosting with preview deployments, so every change has a link you can test.
- Add accounts and email together. Verify your sending domain with the provider and leave its sandbox mode, or your verification emails will only reach you.
- Test sign-up on a preview before you share it: a new address, the email arrives, the link goes to the preview and not
localhost, and the account works afterwards. - Add analytics and error tracking before launch, not after the first complaint.
If you build with Qoder, you can connect Proxy Mail QA from the Qoder Marketplace and ask the agent to check the sign-up email after every change to your auth code. How that works.