Skip to main contentSkip to footer
    Back to Case Studies
    Peptide ReligionResearch peptides, e-commerce
    E-CommerceNext.js 16Multi-Brand

    Peptide Religion

    A research-peptides storefront built so the same codebase can ship a second brand by adding one config file. A questionnaire funnel turns ad clicks into a product recommendation, and a payment-provider engine keeps checkout working when a processor goes cold.

    9
    Steps in the /qualify recommendation funnel
    3
    Ad landing-page variants under /lp
    18
    Products in the catalogue data layer
    3
    Workspace packages: frontend, shared, api

    Brand as configuration

    Name, domain, logos, colours, radii, fonts, hero copy, value props, disclaimers and feature flags live in one typed BrandConfig. The theme is written to CSS custom properties on the html element, and every component reads tokens like bg-brand-cta.

    Qualification funnel

    Nine steps at /qualify with conditional branching, single and multi-select cards, a progress bar, a calculating screen, results with recommendation cards, and account creation at the end. State persists in session storage through Zustand.

    Ad landing pages

    Statically generated variants at /lp/weight-loss, /lp/recovery and /lp/anti-aging, each with its own headline, hero image and feature list, wired to the funnel and reading campaign params inside a Suspense boundary.

    Payment-provider rotation

    An API package with a PSP registry, per-site assignments, rotation events, volume tracking, cascade and cooldown logic, plus a scheduled Vercel cron that reactivates cooled providers.

    Security by default

    HSTS with preload, X-Frame-Options DENY, nosniff, strict referrer policy and a locked-down Permissions-Policy on every route, a CSP report endpoint, CSRF and rate-limit helpers, and Zod schemas on input.

    Accounts, cart, checkout, admin

    Supabase auth with SSR helpers, Drizzle over Postgres, cart and checkout stores, order and wallet APIs, and an admin area for products, orders, coupons, payment providers and security events.

    The brief

    Peptide Religion sells research peptides online. The products are furnished for in-vitro study only, and the site says so on every page, so this is a case study about an e-commerce build, not about the compounds. The brief had three parts that most storefront builds do not: the operator wanted to run more than one brand on the same platform, wanted paid traffic to land on a page that qualifies the visitor before showing a catalogue, and needed checkout to survive the payment-processor churn that this category is known for.

    Design constraints we set

    • One codebase, many brands: A new storefront should be a config file and a set of logo assets, never a fork.
    • Qualify before you sell: Ad traffic goes through a questionnaire that ends in a recommendation and an account, not a bare product grid.
    • Never lose a checkout to a processor: Payment providers are a pool with rotation and cooldown, not a single hard-coded integration.
    • Compliance copy is code: Research-use disclaimers are typed fields on the brand config and render from there.

    How it works

    Brand theming through CSS custom properties

    Every storefront is a BrandConfig object in the shared package: identity, a theme block with primary, secondary, accent, background, text, CTA colours and three border radii, hero copy, value propositions, company details, the research disclaimer, the footer disclaimer, and feature flags for crypto, ACH, peer-to-peer and wallet payments, coupons, tier pricing and mandatory registration. At runtime the site id selects the config, the theme values are set as custom properties on the html element, and Tailwind 4's CSS-first configuration exposes them as utilities. Components never mention a hex value; they use bg-brand-cta, text-brand-accent and rounded-brand-card.

    The qualification funnel

    The funnel lives at /qualify with an optional catch-all step segment so every step has its own URL. Nine step configurations drive a renderer that picks the right component: single-select, multi-select, acknowledgment, account form, calculating screen and results. Steps can be conditional; the previous-compounds question is skipped for visitors who say they are new. Answers persist in session storage through a Zustand store, so a refresh does not restart the flow. The recommendation engine maps the research goal to product ids, filters by the budget bracket, attaches a reason string per product and adds bacteriostatic water when a recommended product needs it.

    Landing pages for campaigns

    The /lp/[variant] route pre-renders three variants with generateStaticParams. Each has its own headline, subheadline, hero image and feature bullets, and a call to action that seeds the questionnaire store before sending the visitor into the funnel. Because the landing component reads search params for campaign attribution, it is wrapped in Suspense, a Next.js requirement that the project's memory file records as a gotcha so it is not rediscovered the hard way.

    Payment providers as a pool

    The api package holds a Drizzle schema with a PSP registry, per-site assignments and rotation events, and an engine with resolve, rotate, cascade, cooldown and volume-tracking modules. Checkout asks the engine which provider to use for a site and payment type; a provider that fails or hits its volume ceiling is rotated out and put into cooldown, and a scheduled Vercel cron, protected by a bearer secret, reactivates providers whose cooldown has expired. The admin area exposes the PSP table and a security-events log alongside products, orders and coupons.

    What shipped

    Home, about, contact, products index and per-product pages, cart, checkout, account, privacy, terms and a research-disclaimer page
    Nine-step qualification funnel with results and account creation
    Three statically generated ad landing pages under /lp
    Auth, orders, wallet and checkout APIs (payment config, process, webhook)
    Admin: products, orders, coupons, payment providers, security events
    Payment-provider rotation engine with a scheduled cooldown job
    Security headers on every route via the Vercel config, a CSP report endpoint, CSRF and rate-limiting helpers

    Problems worth talking about

    Theming without a build step

    Tailwind 4 reads the brand variables directly, so switching brands does not require a rebuild of the utility layer. The trade-off is discipline: the conventions file bans raw colour values in components.

    Every funnel step is a URL

    An optional catch-all segment gives each step a route without one file per step, which keeps back-button behaviour and analytics per step honest.

    Checkout that outlives a processor

    Rotation, cascade and cooldown are data in Postgres, not conditionals in a route handler, so an operator can add a provider from the admin instead of a deploy.

    Monorepo on Vercel

    Workspace dependencies mean the frontend cannot be installed alone, so the deployment is prebuilt locally and pushed with the prebuilt flag; the root package pins Next only for framework detection.

    Where it stands

    What we can and cannot claim

    This page describes the platform as it exists in the codebase; the step, variant, product and package counts are code-verified. We make no claims about the products themselves: the site's own disclaimer states they are for laboratory research use only, and nothing here should be read as a health or medical statement. We have not been given analytics or sales data for this project, so there are no traffic, conversion or revenue figures. The api package's PSP engine is wired and scheduled; broader payment integrations are on the roadmap.

    Build your profile.

    — Peptide Religion, funnel entry

    What This Project Does Well

    Multi-brand from day one: the brand registry maps a site id to a config, and an unknown id throws at startup rather than rendering a half-themed store
    Tailwind 4 CSS-first theming with @theme inline, so brand tokens are real CSS variables rather than a compiled palette
    The research-use disclaimer and the footer legal text are part of the brand config, so they cannot be dropped from a storefront by accident
    A recommendation engine that maps six research-goal answers to products, filters by budget range and adds the reconstitution consumable automatically
    Named exports only, strict TypeScript, server components by default: conventions are written down and enforced in the project memory file
    Prebuilt Vercel deployment, so what ships is exactly the build that was verified locally

    Technologies Used

    Next.js 16.1 App Router with Turbopack, React 19.2, TypeScript strict, Tailwind CSS 4, Zustand 5 with persist middleware, Zod, Supabase (supabase-js and @supabase/ssr), Drizzle ORM over Postgres, pnpm 10 workspaces, Node 24, Vercel with cron jobs, DM Sans

    Ready to Build Something Similar?

    Let's discuss how we can help transform your business with a custom digital solution.

    📅 Schedule Consultation