All work

    PixelGrowth

    Cold email infrastructure with a built-in tool suite

    ReactTypeScriptSupabaseReact QueryRadix UITailwindSMTP / IMAP

    Role: Sole engineer — platform architecture, Supabase schema, tool suite, warmup system, deliverability logic. · Updated 2026-09-01

    What's actually in it

    114
    Modules in graph
    madge dependency graph of the source repo
    23
    Routes
    incl. six standalone tool routes
    6
    First-party tools
    List Cleaner, Copy Writer, Subject Tester, Send Planner, Audit Report, Spintax
    61
    Frontend deps
    production package.json dependencies

    The problem

    Agencies running cold email were stitching together four SaaS subscriptions: one for sending, one for warmup, one for list hygiene, one for copy. Every handoff between them lost data and nobody could attribute a reply back to a subject line.

    What I built

    • 01Built a 23-route platform covering accounts, campaigns, contacts, pipeline, inbox, unibox, warmup, analytics, workflows, and API docs.
    • 02Shipped six first-party tools as their own routes rather than buried features: List Cleaner, Copy Writer, Subject Tester, Send Planner, Audit Report, and Spintax.
    • 03Built the warmup system to run against real mailboxes on a dedicated domain, so reputation is built on the same infrastructure that later sends.
    • 04Unibox consolidates replies across every connected sending account into one thread view, so a reply is answered from the account it landed on.
    • 05Workflow engine with a shared catalog module — the single most-imported file in the graph — so new automation steps register in one place.

    Building something in this shape? Book a 30-min scope call →

    Walkthroughs

    The developer POV video is the one worth your time — it walks the dependency graph, the route map, and the data layer rather than clicking through screens.

    Developer POV — architecture walkthrough114 modules, 23 routes, and the catalog pattern that keeps the workflow engine from sprawling.
    Screen tour — inside the running appFive screens from the logged-in app: dashboard, email warmup, campaigns, analytics, and settings. Mailbox addresses are blurred because several of those inboxes belong to clients.

    Engineering decisions

    Tools as routes, not modals

    Every tool has its own URL. That means an agency can hand a VA a link to the List Cleaner without giving them the campaign dashboard, and it means each tool is independently linkable from the docs.

    A single workflow catalog module

    components/workflows/lib/catalog.ts is the most-imported file in the codebase. Every workflow step type is declared there once. Adding a step is one entry, not a change across the builder, the runner, and the display layer.

    Warmup on owned infrastructure

    Warmup mailboxes live on a domain the platform controls. Renting warmup from a third party means your sending reputation is built on someone else's IP pool and disappears when you churn.

    The product

    Dashboard — 10 sending accounts, 8 campaigns, average inbox reputation 78, with per-campaign send/open/reply/bounce underneath.
    Email warmup — reputation trend, the 30-day volume ramp, and a per-mailbox card showing where each inbox is in its schedule.
    Campaigns — sequence state, sending-account binding, and live open/bounce counts per campaign.
    Analytics — 14-day warmup activity, campaign comparison, and top performers by open rate.
    Settings — custom open-tracking domain via CNAME, seed inboxes for placement testing, and Gemini-generated warmup bodies so every warmup email is unique.

    Want something built the way PixelGrowth was?

    Bring the problem, not a spec. 30-minute call — I'll tell you what it actually takes to build, what I'd cut, and what it costs. No decks, no discovery phase invoice.

    Related builds