Dieture Website

Selling a subscription is not selling a product. A visitor has to understand the plans, trust the nutrition behind them, pick something that fits their goals, and then keep managing that choice long after the first purchase — pausing, changing plan, adding items, booking a dietitian.

Doing all of that on one site means the marketing surface and the account surface cannot be two products bolted together, which is the usual outcome once the pages marketing owns and the flows engineering owns start drifting apart.

I led the build with two other developers. We treated content as data from the start: plans, copy and campaign pages come from a headless CMS, so marketing can change an offer or launch a landing page without a deploy and without a developer in the loop.

Everything that affects conversion is instrumented. Event tracking runs the length of the funnel — plan view, plan selection, onboarding step, checkout — so "where do people drop out" has an answer in the data rather than an opinion in a meeting.

• Meal-plan discovery and comparison, driven from CMS content
• Dietitian appointment booking
• Addon purchase and subscription management for existing customers
• End-to-end onboarding, from first visit to an active subscription
• Marketing tooling and funnel event tracking wired through the whole flow

Three people on one front end only works if the boundaries are decided before the code is. We split by flow rather than by layer — discovery, onboarding, account — over a shared component and data layer, so two of us were rarely editing the same file and the seams between flows stayed visible in review.