Normalerweise shipe ich Next.js als Docker-standalone auf ECS Fargate — ALB, VPC, always-on Tasks. Für ein MVP wie qr-plakat.de bin ich stattdessen OpenNext 4.x + AWS CDK gegangen. Günstiger im Betrieb, schneller zu iterieren. Wenn das Produkt funktioniert, wechsle ich vielleicht zu Fargate.
Drei Dinge fühlten sich besser an als der Fargate-Weg. Deploys sind ein GitHub-Actions-Job von Lint bis CloudFront-Invalidierung. Infra ist CDK, das ich schon kenne — explizite Stacks, kein extra Deploy-Produkt. Und ich kann aus Telegram → OpenClaw → Cursor shippen, während ich Netflix schaue oder draußen trainiere: PR landet, Actions deployed, ich checke Prod vom Handy.
Das Produkt: qr-plakat.de
qr-plakat.de ist ein DACH-SaaS für Plakate mit QR-Codes. Im Wizard designen, ein bis acht Codes overlayen, 300-dpi-PDF oder JPG exportieren. Jedes Plakat bekommt gehostete Scan-URLs wie qr-plakat.de/p/{slug}, die du ohne Neudruck ändern kannst. Alles läuft in eu-central-1.
Das erste echte Plakat ist das Brasil-Schaufensterplakat — acht Produkte, acht QR-Codes, druckfertig aus dem Editor.
Abos sind gemockt. Ich bin der einzige User, kein Stripe-Checkout. Will jemand ein höheres Tier, fragt er im Support-Chat an und ich setze den Plan manuell. Echtes Billing kommt, wenn ich das erste Business überzeuge.
Warum OpenNext + CDK für ein MVP
OpenNext + CDK ist die beste Wahl für MVPs — niedrige Kosten, schnelle Iteration. Wenn das Produkt funktioniert, wechsle ich vielleicht zu ECS Fargate.
Fargate will Baseline-Tasks, VPC und ALB — auch wenn fast niemand die Site trifft. OpenNext mappt die Next.js-App auf pay-per-request Lambda, mit CloudFront und S3 davor. App Router, RSC und Server Actions bleiben. Kein next start im Container.
Ich bin bei CDK geblieben — explizite Stacks, dieselbe IaC, die ich sonst nutze. DynamoDB, S3 und Cognito heißen kein VPC für die Data Plane.
Der ECS-Fargate-Weg von listings-mcp ist die spätere Stufe: always-on, lange Jobs, wenn Traffic und Product-Market-Fit es rechtfertigen.
Stack
| Layer | Tools |
|---|---|
| Frontend | |
| Hosting | @opennextjs/aws → |
| IaC | NextjsSite |
| Auth | |
| Data | |
| DNS | qr-plakat.de |
GitHub Actions — der Teil, den ich liebe
Ein Job. Kein Artifact-Hop zwischen Build und Deploy. Der Runner lintet, typecheckt und testet, dann next build, open-next build, cdk synth. Danach IAM-Rolle per OIDC, cdk deploy --all, CloudFront /* invalidieren.
PRs auf main shippen Prod. Absichtlich. Dependabot nur CI.
Deshalb funktioniert Telegram-Shipping: Agent öffnet PR, Actions deployed, ich checke live vom Handy.
Agentischer Loop
Über OpenClaw und drei Monate später habe ich schon geschrieben. Auf diesem Projekt derselbe Loop, nur auf qr-plakat gerichtet.
Voice oder kurzer Text auf Telegram — Netflix oder Training draußen. OpenClaw auf dem VPS gibt an Cursor im echten Repo. Cursor macht git pull, liest AGENTS.md und docs/, implementiert, öffnet PR. Produktentscheidungen in docs/ und ADRs — nicht im Chat vergraben.
MCPs, die ich wirklich genutzt habe
Cursor mit wenigen MCPs auf dem Repo. shadcn für Komponenten. aws-knowledge-mcp für AWS-Docs beim CDK-Schreiben. playwright für Browser-Checks. firecrawl zum Scrapen/Recherchieren. sistrix für DACH-SEO. pdf-reader für Print- und Export-PDFs.
Skills, die geholfen haben
Die nützlichen Skills hatte ich schon: aws-cdk-development und aws-serverless für Infra, vercel-react-best-practices, shadcn-ui, tailwind-patterns für die App, ci-cd-pipeline-builder für Actions, seo-audit und seo-meta für Landing Pages, plus playwright-cli, diagnosing-bugs, code-review.
Kein OpenNext-spezifischer Skill. CDK- und Serverless-Skills reichten.
Würde ich es wieder machen
Für ein MVP: OpenNext + CDK + ein Actions-Job + Telegram-Agents. Günstig, schnell shippen. Wenn qr-plakat durchstartet, vielleicht Next.js auf ECS Fargate. Bis dahin serverless.
Live: qr-plakat.de.
office@martinmueller.dev · calendly.com/martinmueller_dev · LinkedIn