Four products, shipped end to end.

The problem

JobHackers teaches that most offers come from the hidden job market — conversations, not applications. But members tracked effort in spreadsheets, coaches had no visibility, and access to the programme was handled by hand.

What I built

• Tracker — weekly actual / target / variance per activity category, with the 80/20 hidden-vs-visible split front and centre.
• CRM — contacts, interactions (info / job / pleasure interviews, thank-yous) and an opportunities board; CSV import with duplicate detection and two-way company linking.
• Compass — a single "True North" goal statement, plus a reading rail pulled from Ghost CMS.
• JobHacking portal — Narrative, True North, Target companies and Artefacts rendered from one profile.yml, with read-only share links.

The hard parts

• Time-boxed access — payment webhook → Firebase Admin creates the user + a 3-month grant with a 24–48h redeem window; expiry drives a paywall with admin-editable copy.
• Admin portal — four tabs (TOFU funnel, lead-magnet CMS, user interactions, analytics) where every editor sits beside a true-size preview of the real screen. Content saves deep-merge so one tab can never clobber another.
• Two databases on purpose — Firestore for app data, Supabase for an append-only event log tagged by AAARRR stage.

The problem

New migrants have thin or no local credit history, so mainstream lenders say no. A community lender wanted to say yes responsibly — but needed identity verification, affordability evidence and an audit trail that stands up to the CCCFA.

What I built

• Two customer models — online applicants via Firebase Auth, and offline customers (friendly IDs like TERE001) created by the lender and later claimed through 3-way verification (email + DOB + name).
• KYC onboarding — intro → email → mobile OTP (Twilio) → profile → identity documents, gating every loan application.
• Lender workspace — applications, customers, portfolio, benchmarks, repayment schedules with early-repayment interest rebate, and a PDF affordability report.
• Admin + content editor — feature flags, integrations, email templates, users.

The hard parts

• Security by default — every state-changing route goes Zod → withAuth() → Upstash rate limit → reCAPTCHA → business logic → auditLog(). Clients never write to Firestore directly.
• Thin-file applicants — no bureau score to lean on, so affordability has to be evidenced from statements and behaviour. See the credit model below.
• PII encryption — application-layer AES-256-GCM with key versioning so keys can rotate without re-encrypting the world.

The problem

Leads arrived from webinars, newsletters, LinkedIn, a quiz and a product — each in its own tool. Nobody could answer "where do we leak?" or "who should I contact today?" without a spreadsheet afternoon.

What I built

• AAARRR dashboard — Awareness → Revenue KPI cards with per-stage CSV export; funnel, bar, trend, mix, source-matrix and sub-step views over the same filters.
• People page — one row per email, combining every interaction into a single intent score and an intent × fit quadrant with a recommended action per segment.
• Experiments & targets — weekly targets, cohorts and experiment-impact windows.
• Integrations — LinkedIn OAuth import, GA4 for awareness, cron-driven sync.

The hard parts

• Scoring in Postgres — intent = stage_weight(furthest stage) + tag_points − decay; churn always ≤ −1, everyone else ≥ 0. Weights and tag rules are tables, editable from the admin UI.
• Two grains, deliberately — row grain for the event log, person grain (lead_people view) for outreach. Behaviour never feeds fit; quiz never feeds intent.
• Stages go backwards in real data (an old email click logs activation after retention), so "effective stage" is the furthest ever reached — unless the latest event is churn.

The problem

Webinar incumbents charge ~$100/month, cap attendees, and make you bolt on Slido-style tools. For a community that runs a weekly session, the engagement is the product — so I built the engagement layer first and treated video as a commodity.

What I built

• Communities — a room an organiser owns: colour, logo, public page, upcoming and past events; every event is also a registration page with seats and a waiting list.
• Frictionless attendance — register with name + email, get a personal link and join code; reminders on paid plans; registered vs turned-up reporting.
• The room — PDF deck presented live, presenter video in the corner, waiting room with image / video / audio, six floating reactions, chat, Q&A with upvotes.
• Activities — presenter-authored polls, scored quizzes, word clouds and CTAs with timers; results reveal as an overlay (tally, cloud or leaderboard) when the organiser says so.

The hard parts

• Cost-shaped architecture — 2–3 presenters on WebRTC, everyone else on HLS with no socket. Promote-to-stage pre-warms the publish token and camera prompt so the hop is only the connect.
• Latency-aware sync — HLS viewers sit 2–5s behind. Clients measure their live-edge latency and delay slide changes and activity openings so they land with the audio.
• Realtime without postgres_changes — 100 clients subscribing with RLS is slow, so a trigger broadcasts every write to one session:{id} channel and the client runs a reducer. Answers are rejected and quizzes scored in the database, not the browser.