Skip to main content
PARIS, FRANCE
CV
CASE 03 / LAUNCHPATH
LIVE PRODUCT

ONBOARDING ORCHESTRATION

LAUNCHPATH

A calm operating system for work that begins before day one and continues long after it.

ROLE
Product design
Full-stack implementation
SCOPE
Product UI · server actions
Data model · access + business rules · tests · deployment
AUDIENCE
Operations and people teams
Managers and task owners
PERIOD
2026 iterations
Deployed prototype
STACK
Next.js 16React 19TypeScriptPostgreSQLSupabase
CONSTRAINT
Business-day scheduling
Tenant-safe history
CONTEXT / RESULT
Portfolio product
Deployed prototype
CODE
Private repository
Architecture documented
TECHNICAL READ

Snapshots, scheduling and isolation at a glance.

Role and scope are stated above. This index isolates the system boundary, the mutable-state problem, the decision and its proof.

ARCHITECTURE
Server actions → scoped queries → PostgreSQLSession, organization and role are rechecked before every mutation.
HARD PROBLEM
Templates change while journeys runAn edit must not rewrite the plan already assigned to a person.
KEY DECISION
Snapshot the plan at launchTemplate name and ordered steps become independent journey and task rows.
PROOF
Copied state is inspectedDatabase tests read 3 copied tasks and the copied template name.

01 / THE OPERATIONAL GAP

A copied checklist cannot run a living process.

Each onboarding lived in a different copy: unclear deadlines, manual reminders and no shared view of progress.

I built one simple rule: define the path once, launch it for each person, then make owners, business-day dates and delays visible.

02 / THE SCHEDULING ENGINE

Relative intent becomes a real calendar.

Each template step stores an owner and an offset. At launch, one pure function calculates dates in business days from the arrival date.

-03Prepare accessBefore arrival
00WelcomeStart date
+05First reviewWeek one
+30Feedback loopMonth one

START DATE + BUSINESS-DAY OFFSET = SHARED DUE DATE

03 / THE WORKING JOURNEY

Progress reads like a path, not a spreadsheet.

Numbered folios expose position, overdue states make delay explicit and the activity history preserves who changed what.

LAUNCHPATH / OPERATIONS DASHBOARD03 ACTIVE
LaunchPath dashboard with next action, metrics and active journeys
01 / OPERATING VIEW

The dashboard surfaces the next checkpoint, active journeys and delays before the team opens a single record.

LAUNCHPATH / ACTIVE JOURNEY03 / 08
Clara Nguyen active journey with trajectory, owners and delays
02 / ACTIVE JOURNEY

The trajectory, owners and business-day deadlines remain visible together, so the team can act without reconstructing context.

04 / ENGINEERING DECISION

Launch copies the plan instead of linking to it.

  1. 01

    PROBLEM

    A mutable template must not rewrite an onboarding already underway or erase the name it started from.

  2. 02

    CHOICE

    At launch, the template name and ordered steps are copied into the journey and its tasks, with assignees and computed due dates.

  3. 03

    WHY

    Each running journey becomes an independent snapshot; later template edits only affect future launches.

  4. 04

    TRADE-OFF

    Template fixes do not propagate automatically to active journeys and must be applied explicitly when needed.

TECHNICAL PROOFS

Three rules. Three inspectable checks.

Each card points to an exact expectation or implemented path confirmed in the source repository.

  1. A / UNIT TEST

    The weekend is skipped

    CLAIM
    Friday 13 Mar 2026 + 1 business day must land on Monday
    MECHANISM
    addBusinessDays() advances through civil dates and counts Monday to Friday
    PROOF
    scheduling.test.ts expects Monday 16 Mar 2026
  2. B / DATABASE TESTS

    A launch becomes a snapshot

    CLAIM
    A journey must keep the plan used at launch
    MECHANISM
    The transaction copies the template name and ordered steps into journey + task rows
    PROOF
    Integration tests read 3 copied tasks and the copied template name
  3. C / DATABASE TEST

    Organization isolation holds

    CLAIM
    Organization A submits Organization B’s task ID with status = done
    MECHANISM
    findOwnedTask() requires both the task ID and current organization ID
    PROOF
    Integration test: the action is ignored; Organization B’s task remains todo

05 / TRUST BOUNDARIES

Multi-tenant by construction.

Every mutation rechecks the session, organization and role.

The browser never reaches business data directly: deny-all RLS below, one verified server path above.

06 / QUALITY AS PRODUCT BEHAVIOR

181 passing cases. Three levels of confidence.

181 counts individual passing test cases across three commands, not 181 user journeys: 91 unit cases, 86 database integration cases and 4 browser journeys.

Source: private LaunchPath repository · pnpm test / test:db / test:e2e · verified 10 Oct 2026 · 0 failures

91unit test cases

Dates, scheduling, session and redirect safety.

86database integration cases

Real constraints, snapshots and tenant isolation.

04browser journeys

Critical flow and responsive behavior in Playwright.

The hardest bugs were not visual.

A risky migration, a premature UI refresh and a falsely green test each became a stronger boundary and a more honest verification path.

07 / WHAT THIS PROJECT PROVES

I can design the journey
and engineer its reliability.

Workflow, interface, business rules, data boundaries and verification were designed as one product system.

  1. 01
    PRODUCT MODEL

    Turn a scattered process into explicit rules

    Templates, owners, offsets and statuses replace copied documents.

  2. 02
    INTERACTION DESIGN

    Keep the next action visible

    Folios, phases, URL-driven detail and history preserve context.

  3. 03
    BUSINESS LOGIC

    Encode time as a product rule

    One pure function handles positive and negative business-day offsets.

  4. 04
    DATA & SECURITY

    Make isolation impossible to forget

    Scoped queries, verified memberships and deny-all RLS protect every path.

  5. 05
    DELIVERY QUALITY

    Test the promises teams depend on

    Unit, database and end-to-end tests cover critical behavior.

08 / OUTCOME

Operational clarity, encoded.

LaunchPath demonstrates reusable templates, business-day scheduling, collaboration and tenant-safe data access in one product system.

Assignment emails and the secured, idempotent reminder endpoint are implemented. Automatic production scheduling and delivery monitoring are not configured in this repository yet.

IMPLEMENTED
Assignment emailsSent after launch and reassignment, outside the data transaction.
IMPLEMENTED
Reminder engineA secured endpoint handles due-soon and overdue emails without duplicate sends for the same day.
TO CONFIGURE
Production schedulerConnect and monitor a daily trigger before presenting reminders as an automated production service.

09 / THE NEXT PILOT

Validate the path
before automating more.

The next useful release is not another feature. It is a measured pilot with operations teams that proves the model makes ownership clearer and delays easier to act on.

  1. 0101 / OBSERVE

    Run real onboardings

    Follow a small cohort from template authoring to the final activity event.

  2. 0202 / MEASURE

    Compare delays and ownership

    Measure overdue-task reduction and how quickly an owner can identify the next action.

  3. 0303 / DECIDE

    Connect only proven automation

    Schedule the existing reminder endpoint, then add integrations only where the pilot shows repeated manual work.