Problem

The challenge was combining multiple content streams, non-developer publishing through Notion, external feed aggregation, and real checkout and fulfillment in one maintainable app.

Context / users

I built one codebase for editorial content, curated media, news aggregation, and a small store. The point was not to split those concerns across separate systems.

Solution

I split content access, feed assembly, order persistence, and fulfillment into separate layers. On the backend, route handlers validate input, create Stripe sessions, verify webhooks, persist orders, and submit fulfillment requests.

• Notion-backed publishing for voices, curated videos, journal entries, book-club content, and protest music
• Unified feed architecture that merges RSS, curated media, and editorial content
• Configuration-driven sticker catalog with multiple products, bundle options, and mix-and-match cart pricing
• Stripe Checkout flow for both legacy single-product purchases and cart-based checkout
• Supabase-backed order storage with fulfillment status tracking
• Printify integration for order submission, production handoff, shipment updates, and tracking links
• Order status pages for customers after purchase
• Reusable metadata helpers for Open Graph and Twitter cards across editorial and product pages

Architecture

Notion mapping, feed aggregation, checkout, and fulfillment all live behind explicit module boundaries. The codebase supports multiple content types and a commerce pipeline without turning into one giant page file.

Engineering Details

• • Next.js 15 App Router and React 19 for route-based separation between content pages, product pages, and API handlers
• • Repository-style Notion modules with pagination helpers instead of querying Notion directly inside page components
• • Feed services use `unstable_cache`, `p-limit`, and `Promise.allSettled` to reduce repeated API work and degrade gracefully when one source fails
• • Utility-layer normalization for slugs, YouTube IDs, thumbnails, and lightweight content cleanup
• • Strict environment validation and server-only modules for secrets and admin clients
• • Stripe webhook signature verification using raw request bodies before order creation
• • Retry logic around transient database and fulfillment operations
• • FulfillmentProvider abstraction keeps Printify-specific logic out of the rest of the application
• • Cron-secured keep-alive, warm-home, and revalidation routes for operational maintenance and cache management

Outcome

• Shipped a live site that combines publishing, aggregation, curation, and commerce in one coherent product
• Created a maintainable content workflow where new editorial material can be managed through Notion instead of code changes
• Built an end-to-end order pipeline: payment, persistence, confirmation, fulfillment submission, shipment update
• Produced a stronger technical portfolio piece than a standard blog or store because the project spans frontend architecture, backend integrations, and operational concerns

Tradeoffs / Limits

• • There is no automated test suite in the repo, so correctness is enforced through code structure and manual verification rather than formal coverage
• • Customer order access is only lightly protected; the API route checks email for full details, but the server-rendered order page currently exposes order data by ID if the URL is known
• • This is not a full commerce platform with inventory, auth, admin dashboards, or complex catalog management; it is intentionally narrower
• • Some operational features, like feed warming and refresh orchestration, appear to rely partly on external scheduling/configuration rather than being fully self-contained in the repo

Why It Matters

It shows real product engineering across content, integrations, and transactions.