Context
Per Chris's 2026-05-07 11:36 AM task drop:
"add a subscription functionality to pawel dregans site (however easiest within our setup there and in aws, maybe actually deploy it as a stacks app instead of a stx one)"
The site is currently a static stx site (built via bun run build → static HTML, no DB / no server runtime). Adding subscription functionality (email capture → mailing list, or paid recurring subscription, or both — needs clarification) means we have a fork in the road:
- Option A — keep stx static, add a serverless backend for subscriptions only (Lambda + API Gateway + DynamoDB or SES, etc.). Site stays cheap and CDN-served; only the subscribe endpoint is dynamic.
- Option B — convert paweldregan to a Stacks app, deployed via our standard Stacks deploy flow. Gives us DB, email, sessions, payments surface for free. Heavier ops footprint, but sets the precedent for
pet-store(which will need the same surface).
Chris's hint leans toward B "maybe actually deploy it as a stacks app instead of a stx one" — but it's a hint, not a decision.
Decision needed (before any implementation)
- What kind of subscription? Email-list opt-in only, or paid recurring (newsletter / coaching slots / training plans)? Different scope.
- A or B? If we expect
pet-storeto need the same backend stack, doing B here first is a useful dry run. If subscription is just an email opt-in, A is way cheaper. - Email destination: if it's a mailing list, where does it land? blocked by #7 (mail-os multi-domain setup for
hello@paweldregan.com).
Acceptance
- Decision documented in this issue thread.
- If A: Lambda + storage + email plumbing in place; subscribe endpoint reachable; opt-in confirmed working end-to-end against a real address.
- If B: paweldregan migrated to a Stacks app with the same public-facing pages + the new subscribe surface; deployed; existing SEO/og/i18n behavior preserved (don't regress #5).