Case study
The system behind the other case studies.
Leangency is the agency I founded and run, and this is its portal — the multi-tenant system every client sits on. This case study is different from the client case studies on purpose: the subject isn't a client delivery, it's the operational infrastructure. The pipeline that finds and qualifies clients in the first place is a separate system with its own case study — Client Acquisition OS.
Why build this instead of buying it
Brenova and Juliana Alves — two of the three other case studies on this site — both sit on the same portal, each on their own subdomain, with their own content, isolated from every other tenant. (Julia Mendes runs on a separate, standalone codebase of her own, not this portal — worth being precise about rather than rounding every client into one system.) That only works at agency scale if provisioning a new client is a repeatable operation, not a bespoke setup each time. So the portal, and the acquisition pipeline that feeds it, are both things I built and own, not a stack of disconnected SaaS tools glued together by hand.
What's built
The portal. A tenant is resolved straight off the
request's Host header — {client}.leangency.com in
production, {client}.localhost in dev — against a
tenant registry, with the apex domain reserved for the agency's
own site. Sign-in is passwordless: a magic link, verified in two
steps rather than one. On 3 July 2026, magic-link tokens started
showing as "already used" for a client using Outlook — her mail
client was prefetching and consuming the single-use link before
she ever tapped it. Fixed the same day with a two-step flow: the
emailed link only validates and shows a confirmation screen; only
an explicit tap consumes the token and starts the session.
Delivery tracking. This is an event-sourced delivery lifecycle, not a full event-sourced system end to end: project and delivery state for the covered flows (stage changes, approvals, milestones) is written as append-only events rather than overwritten in place, with an aggregate observability endpoint — secret-guarded, counts and timestamps only, no payloads — that an operator or an automated check can query to confirm the pipeline is actually receiving and surfacing events. It's deliberately not gated behind the same feature flag as the producers it watches, so it still answers when that flag is off. By the repo's own account this is infra-complete for the delivery and client-review flows, not the full command catalogue the architecture is designed to eventually carry — stated here at that level, not rounded up.
A decision worth explaining
The event log is honest about its own maturity: it's infra-complete and the delivery-seam producer milestone is wired, not the full command catalogue the architecture is designed to eventually carry. Building the append-only spine and the observability endpoint before every producer exists was a deliberate sequencing choice — it means every new capability added from here plugs into a pipeline that's already provably being watched, instead of retrofitting observability once something's already broken silently in production.
Measured, not claimed
The portal is a private, tenant-authenticated system by design — there's no public URL to hand a recruiter the way there is for Brenova, Juliana Alves or Julia Mendes. What's above is scoped to what's directly verifiable in the codebase: the subdomain resolver, the two-step auth fix and the incident that caused it, and the event-log schema and its observability endpoint — not aspirational documentation.
Stack: Next.js 16 · React 19 · TypeScript · Supabase · Sanity CMS · Upstash · Resend · Stripe · Cloudinary · BullMQ · Vercel.
Want the architecture, not just the pitch?
I'm glad to walk through the tenant model, the event schema, or the acquisition pipeline in detail.
Get in touch