Yarn+Chai Members Platform — Serverless Membership Site on Next.js + AWS

2026-06-08

1. Project Overview

Yarn+Chai is a subscription membership platform for a crochet pattern business. Members subscribe through Stripe, browse a pattern library, and follow patterns step-by-step in the browser. A single serverless AWS backend powers three frontends: the members web app, an admin dashboard, and a React Native mobile app.

I designed and built the whole system — frontend, backend, billing, and mobile — for a real business with paying subscribers.

Live site: members.yarnandchai.com

2. Challenge

Off-the-shelf membership tools couldn't deliver what the business needed without locking it into someone else's ecosystem. The requirements that shaped the build:

Gate a growing pattern library behind Stripe subscriptions, with access that reacts the moment a subscription lapses.
Give members a better experience than a static PDF — something to follow step-by-step and return to later.
Keep the existing WordPress authoring workflow intact; the content owner had years of patterns there and no interest in switching editors.
Stay cheap to run against modest, spiky traffic that scales to zero between promotions.

3. Architecture Overview

Shape: Next.js on Vercel → API Gateway → Python Lambdas → DynamoDB / S3 / SQS, with Cognito for auth and Stripe webhooks driving subscription state.

Frontend — Next.js on Vercel. Server-rendered public pages, client-rendered authenticated member experience, edge caching handled by Vercel.
Auth — AWS Cognito, which keeps the trust boundary inside AWS so Lambda authorizers and IAM policies chain cleanly across every backend service instead of needing a translation layer to a third-party provider.
Compute — Python Lambdas deployed with AWS SAM, so the entire backend is infrastructure-as-code and reproducible across dev and prod.
Data — DynamoDB single-table design for member records, pattern metadata, and progress tracking. S3 for pattern PDFs and assets.
Eventing — Stripe webhooks and SQS. Billing changes and pattern publishing flow as events, not polling.
Content source — pattern content stays in WordPress and is pulled through the WordPress REST API, then parsed into navigable steps.

4. Implementation Details

Interactive Pattern Wizard. The feature members use most. Instead of scrolling a PDF, members follow a pattern one step at a time. The wizard pulls content from WordPress via API, parses the heading structure into ordered steps, and persists progress per member in DynamoDB — close the tab, come back a week later, pick up where you left off.

One backend, three frontends. The members web app, the admin dashboard, and the Expo (React Native) mobile app share the same Cognito user pool, DynamoDB tables, and S3 buckets — separated by IAM permissions, not duplicated infrastructure. When the content owner changes a pattern's status in the admin dashboard, the members platform sees it immediately. No sync layer, no eventual-consistency reconciliation.

Subscription state as event flow. Billing is entirely webhook-driven. Stripe is the source of truth for subscription status; a webhook-handling Lambda translates each event into a DynamoDB write and any member-facing SES email. Access reacts to billing without the app ever polling Stripe, and a lapsed subscription propagates in seconds.

Decoupling through SQS. When a new pattern publishes, a message goes onto a queue and downstream consumers — indexing, notifications, cache invalidation — handle their work independently. A slow or failing consumer doesn't block publishing.

The single-table tradeoff, handled honestly. Access patterns are known up front — reads by member ID, pattern ID, and subscription status — exactly what DynamoDB single-table design is good at. The cost is ad-hoc reporting: questions the schema didn't anticipate need a new GSI rather than a quick query. I've added GSIs reactively as reporting needs surfaced. Not elegant, but predictable and cheap.

5. Screenshots

Architecture diagram and product screenshots to come.