Portfolio · 2026 · one project, in depth
IntimPath: a subscription wellness platform, shipped end to end.
Lead engineer from the first commit to release candidate. One Node.js application serving the marketing site, three quiz funnels, checkout with post-purchase offers, a day-by-day coaching app for two audiences in five languages, and the admin behind it. Everything on this page is what I built, with the numbers taken from the repository.
318commits, June to September 2026
66merge requests merged into dev
5languages shipped (en · de · fr · it · es)
335automated test cases, green on every merge
The product
What IntimPath is, and what was mine.
IntimPath sells day-by-day intimacy and sexual-wellness programmes to adults on a monthly or yearly subscription. A programme is 16 to 70 days of lessons (illustrated reading with small quizzes and note boxes), guided workouts (pelvic-floor training with a timer ring and voice cues, or video-led exercises) and audio practices. There are two audiences with their own programmes, funnels and copy.
Customers arrive through three long quiz funnels, pay on a checkout page, see two post-purchase offers and land in the web app. Accounts, payments and subscriptions come from the company's payment platform through an internal SDK. The product layer, the content, the funnels, the app and the operating documentation were mine; a designer landed the visual redesign in parallel.
Scope
- Marketing site, 3 quiz funnels (52–60 screens each), 3 checkout pages, coaching app, admin
- 11 programmes, 415 authored days, 2 audiences
- 5 languages: en · de · fr · it · es
- 7 legal pages generated from counsel's documents
Stack
- Node.js, Express 4, EJS, vanilla JS players and quiz engine
- MySQL with Knex, partitioned tables, migrations
- Tailwind for marketing, hand-written CSS for the app
- node:test (335 cases), Playwright for browser QA
Role
- Lead engineer on the product layer; 318 of 590 commits
- 66 merge requests through review to dev
- Wrote the onboarding and handover documentation
- Consolidated four standalone React apps and an external backend into the one Node app
What I built
Six pieces of the platform, and how each one was kept honest.
Content system: 11 programmes as data
content.js · female-programmes.js · players
Every programme is a JavaScript data tree stitched into one content registry at boot: days, lessons with typed blocks (text, callouts, tables, illustrations, "type here" boxes, locked single-selects, scored assessments with result bands), workouts with per-day difficulty ladders, and guided-audio practices. The Today screen, the reader and the players all render from that one object.
Details that mattered
- Module/Stage headers derived from each programme's authored arc, with a test asserting module sums equal authored days so a header can never point at a day that 404s.
- A follow-on "maintenance" programme gated on completing its parent, pinned at the top Kegel level.
- Shared Kegel level ladder reused across programmes, with the ball artwork bound to the level the workout actually runs.
Proof
- The last programme week I ported came with a mutation-checked test: cap the thumbnail or shift the ladder by one and the case goes red.
- Every content branch shipped with its images, translations and a browser walk-through in the same MR.
Localization for two audiences
de · fr · it · es · ~20 000 keys per language
One dictionary with a neutral base and two gendered overlay namespaces, so a single English source resolves with correct grammatical agreement for each audience. A key blocklist protects identifiers the client compares rather than renders, because translating an enum id corrupts a payload without any visible error.
Result. Both apps fully localized, measured by running the real localizer over every programme and counting what stayed English, not by trusting the dictionary size. The remaining gap when I handed over was one nutrition lesson.
Funnels, signup and checkout
quiz engine · /api/signup · checkout · post-purchase offers
Three JSON-driven quiz funnels feed three checkout skins on one engine. Signup happens on the quiz email screen with a decision matrix (new email, known email on the same funnel, known email on the other audience's funnel) and a magic-link path so an existing customer can log in and pay. Prices come from a mirrored catalogue managed in the admin; the tile copy lives in code with tokens, and a step with no catalogue entry falls back to its shipped numbers rather than an empty paywall.
Details that mattered
- Audience tagged write-once at signup, at purchase and on autologin, so the right programme opens after payment and the shared add-on entitlement cannot cross-unlock.
- Server-side audience gate on every programme, session and lesson route, checked before entitlement.
- Rate limiting keyed by normalized email with a send budget, so payment retries are never throttled.
Proof
- Reported an entitlement-minting flaw in the shared SDK (a forged payment callback) with a reproducible probe, rather than patching around it in product code.
- Checkout flows verified in the browser against a stubbed payment step, with screenshots in the MR.
Media pipeline
ffmpeg · 130+ tracks and loops · transcript-mapped
Voiceovers, timer-ring voice cues and per-exercise workout video loops delivered as multi-gigabyte masters, transcoded to web weights (32 kbps mono audio, 720p CRF-28 video) and wired to exact content slots by transcript rather than by filename or copy. Masters stay outside the repository; only transcodes are committed, by a reproducible build script.
Lesson kept. Never locate a content block by its copy: a reworded caption once left a poster untagged and put two play buttons on screen, one dead. Blocks are anchored on stable paths and the match must be unique, or it warns and skips.
Legal and compliance surfaces
7 pages · generated, not transcribed
Privacy, terms, cookies, subscription, refund, consumer-health and privacy-choices pages. The two counsel-owned documents are regenerated from the redlined Word files by script, with a substitution table for values the code does not back; the rendered text is diffed against the source to prove it verbatim. Claims the code could not honour (a consent UI that did not exist, app-store references) were removed and listed for counsel instead of left in.
The review gate
pre-merge checklist · rules reviewer · browser QA
A pre-merge gate I authored for the team: the CTO's past review comments distilled into a written checklist, a rules reviewer that reads the diff against it, and a browser QA run that walks the changed flows with screenshots. It runs before an MR is opened, and its findings are fixed or answered in the description, never merged past.
What it catches
- A comment claiming a fallback that was unreachable; a stale header describing a range the code no longer had.
- A new card label with no translation in four locales.
- Names the base branch moved out from under a long-lived branch.
Numbers
- Suite grown from zero to 335 cases; each run compared against a pristine base branch by case count.
- Every content MR: reviewer clean + QA 14/14 before the CTO sees it.
Documentation and handover
README · package admin · onboarding · checklist
A README a new engineer can run from; a long-form doc on the price catalogue and package admin; an onboarding page with the customer journey, funnels, checkout states, architecture and repository tree as diagrams; and a handover checklist that separates verified facts from assumptions and the things nobody on the team knew yet.
Result. The project can change hands from one page.
Skills
Stack and strengths
- Backend
- Node.js, Express, EJS, REST APIs, MySQL with Knex, migrations and partitioned tables, JWT sessions, rate limiting, webhook auth
- Frontend
- React 18, TypeScript, Vite, Tailwind, vanilla JS players and quiz engines, responsive mobile-first layouts
- Product plumbing
- Payment-platform integration (checkout, one-click upsells, subscriptions, package/price catalogues), magic-link auth, entitlements and paywalls, marketing pixels and S2S conversion tracking
- Quality
- node:test, Playwright, mutation-checked tests, pre-merge review gates, accessibility and compliance linting
- Content & localization
- Data-driven content systems, i18n with gendered namespaces, translation pipelines, audio/video transcoding with ffmpeg
- Ways of working
- GitLab MR flow, worktree-based parallel branches, written handovers, Confluence documentation, agent-assisted development