Unsere Empfehlung vorab. Wir entwickeln Proxy Mail QA, und fast nichts in dieser Liste ist von uns. Wir empfehlen Proxy Mail QA nur für einen Platz: Wenn deine Website Registrierung, Anmeldung oder Passwort-Zurücksetzung hat oder Konto-E-Mails wie Einladungen sendet, bekommst du damit Test-Posteingänge, um zu prüfen, ob diese E-Mails funktionieren. Wenn deine Website keine Konten hat und keine E-Mails sendet, brauchst du es nicht, und der Rest dieses Leitfadens gilt trotzdem.
Die Liste
| Du brauchst | Wofür | Übliche Optionen |
|---|---|---|
| Einen Ort, um den Code zu schreiben oder zu generieren | Die Website bauen | Einen Editor wie VS Code oder Qoder IDE; einen KI-Coding-Agent wie Qoder, Claude Code oder Cursor; oder ohne Code einen Baukasten wie Webflow, Framer, Squarespace oder WordPress |
| Versionskontrolle | Fehler rückgängig machen, mit anderen arbeiten, deployen | Git, mit GitHub oder GitLab |
| Ein Framework (optional) | Seiten, Routing und Daten, ohne bei null anzufangen | Next.js, Astro, SvelteKit, Nuxt |
| Hosting | Die Website ins Internet bringen, mit einer Vorschau für jede Änderung | Vercel, Netlify, Cloudflare Pages, Render |
| Einen Domainnamen | Deine eigene Adresse und die Absenderdomain für E-Mails | Jeder Registrar; DNS beim Registrar oder bei Cloudflare |
| Registrierung und Anmeldung (wenn Leute Konten haben) | Konten, Passwörter, Codes und Magic Links | Supabase Auth, Clerk, Firebase Authentication, Auth0, Auth.js, Better Auth |
| Eine Datenbank (wenn etwas gespeichert wird) | Konten, Bestellungen, Inhalte | Postgres (Supabase, Neon), Firestore, SQLite |
| Einen E-Mail-Anbieter (wenn E-Mails gesendet werden) | Bestätigungs-, Zurücksetzungs- und Beleg-E-Mails von deiner Domain | Resend, Postmark, Amazon SES, SendGrid, Mailgun |
| Zahlungen (wenn etwas verkauft wird) | Karten, Abos, Rechnungen | Stripe, Paddle, Lemon Squeezy |
| Analytics | Wissen, was Leute nutzen | Plausible, PostHog, Google Analytics |
| Fehlertracking | Wissen, was kaputt ist, bevor Nutzer es dir sagen | Sentry |
| Tests | Wissen, dass eine Änderung Registrierung oder Checkout nicht kaputt gemacht hat | Playwright oder Cypress für den Browser; Vitest oder Jest für Code; Proxy Mail QA für die E-Mails |
| Prüfwerkzeuge | Geschwindigkeit, Barrierefreiheit, Links, SEO | Lighthouse, axe DevTools, ein Link-Checker, Google Search Console. Mehr unter Werkzeuge zum Bauen und Prüfen meiner Website |
| Rechtliche Seiten | Datenschutzerklärung, AGB, Cookie-Hinweis wo nötig | Geschrieben für deine Website und dort, wo deine Nutzer sind |
Was du weglassen kannst
- Eine Website ohne Konten (ein Portfolio, ein Café, eine Landingpage): ein Baukasten oder ein Framework, Hosting, eine Domain und Analytics. Ein Formulardienst, wenn du Nachrichten willst. Keine Authentifizierung, keine Datenbank, keine E-Mail-Tests.
- Ein Shop: Eine gehostete Shop-Plattform wie Shopify deckt oft Hosting, Zahlungen, Konten und E-Mail in einem ab, und du testest, was du dort ändern kannst.
- Eine App mit Konten (ein SaaS-Produkt, eine Community, eine Buchungsseite): fast die ganze Liste. Am häufigsten vergessen werden die Einrichtung des E-Mail-Anbieters und das Testen der E-Mails.
Wo Proxy Mail QA hineinpasst
Sobald sich Leute registrieren können, verschickt deine Website E-Mails, die funktionieren müssen: den Bestätigungscode oder -link, das Zurücksetzen des Passworts, die Einladung. Die gehen auf Arten kaputt, die andere Tests nicht finden. Ein Link zeigt auf localhost, der Anbieter ist noch im Sandbox-Modus und sendet nichts, oder es gehen zwei E-Mails statt einer raus.
Proxy Mail QA gibt dir für jeden Versuch eine neue private Testadresse, zieht den Code oder Link heraus und prüft, wie die E-Mail verschickt wurde. Du kannst es von Hand im Browser mit Proxy Mail QA for Chrome nutzen, in Playwright- oder Cypress-Tests mit dem npm-Paket oder über einen KI-Agenten wie den von Qoder mit dem MCP server. Der kostenlose Plan umfasst insgesamt 500 Testadressen.
Es baut, hostet oder gestaltet nichts und verschickt keine E-Mails für deine Website: Einen E-Mail-Anbieter brauchst du weiterhin.
Ein erster Stack für eine App mit Konten
Eine Möglichkeit, ihn zusammenzustellen, wenn du mit Qoder baust:
- Code: der Agent von Qoder, in einem Git-Repository auf GitHub.
- Framework und Hosting: Next.js auf Vercel, mit einem Preview-Deployment für jeden Branch.
- Konten und Daten: Supabase, für Registrierung, Anmeldung und die Datenbank.
- E-Mail: Resend, Versand von deiner eigenen Domain. Die eingebaute E-Mail von Supabase sendet nur an dein eigenes Team, ein paar pro Stunde. Richte also deinen eigenen E-Mail-Anbieter ein, bevor sich jemand anderes registriert.
- Fehler: Sentry.
- Tests: Playwright für den Registrierungsablauf, mit Proxy Mail QA für die Bestätigungs-E-Mail, ausgeführt bei jedem Preview-Deployment.
Jede Zeile lässt sich durch eine andere aus der Tabelle ersetzen. Die Reihenfolge ist wichtiger als die Marken.
Die Reihenfolge der Einrichtung
- Kauf die Domain früh. E-Mail-Anbieter brauchen sie, um in deinem Namen zu senden, und die DNS-Einträge für SPF, DKIM und DMARC können eine Weile brauchen, bis sie greifen.
- Richte Repository und Hosting ein, mit Preview-Deployments, damit jede Änderung einen Link hat, den du testen kannst.
- Füge Konten und E-Mail zusammen hinzu. Verifiziere deine Absenderdomain beim Anbieter und verlass den Sandbox-Modus, sonst erreichen deine Bestätigungs-E-Mails nur dich.
- Teste die Registrierung auf einer Preview, bevor du sie teilst: eine neue Adresse, die E-Mail kommt an, der Link führt zur Preview und nicht zu
localhost, und das Konto funktioniert danach. - Füge Analytics und Fehlertracking hinzu, vor dem Launch, nicht nach der ersten Beschwerde.
Wenn du mit Qoder baust, kannst du Proxy Mail QA über den Qoder Marketplace verbinden und den Agenten bitten, nach jeder Änderung an deinem Auth-Code die Registrierungs-E-Mail zu prüfen. So funktioniert das.