Case study · Client portal · October 2026
A 14-page client portal, built and handed over in 3 days
A US cold-email agency wanted one place where each of its clients sees campaigns, replies and booked meetings. I built it in 29 hours over 3 days and handed it to the agency's developer.
1
2
- Client
- US cold-email agency
- My role
- Sole builder, design to handover
- Build time
- 29 hours*
- Calendar
- 3 days, 16–18 Oct 2026
- Stack
- Next.js, Supabase, Vercel, Instantly API
- Status
- Handed over, Oct 2026
- White-label safe
- Yes
* Clock time: my hours plus the hours AI agents worked on their own. Parallel agents count once. Waiting time is left out.
The problem
The agency books meetings for its clients through cold-email campaigns on Instantly. Each client had a weekly report, an "interested lead" alert and a booking reminder, built as three automation flows and copied by hand for every new client. In the owner's words, "they break all the time, it's a mess."
He wanted one dashboard where each client sees "literally everything they need". There was no mockup ("I want you to wing it"), and one number mattered most to him: positive reply → booked.
What I delivered
- Overview: Overview, Stats, Reports (weekly, monthly, quarterly, save as PDF), Campaigns
- Leads: Unibox, Pipeline, Calendar, Customer Journey, Follow-up
- Growth: Nurture, Reactivation
- Account: Support, Alerts, Settings
Fourteen client pages and 89 merged pull requests in the 3 days. The delivered app has 868 unit tests, and a browser test signs in and opens every page at desktop and phone width, and it passed on production.
1
2
1
2
1
2
1
2
Three decisions
- Access rules live in the database, not in the screens. With row-level security in Postgres, a client's login can only read that client's rows, so a bug on one page can't leak another client's leads.
- Every number got a written rule before it got a chart. A positive reply counts once per person, on the day they first showed interest. Each report prints the rules under "How we calculate this", and a client can check them against Instantly.
- Some features had no table yet in the developer's database. Those pages show an empty state and a "Coming soon" button. Better than a broken page.
What went wrong
I built the client side on my database while the agency's developer built the admin side on his. I joined the two on 18 October, and the switch took 6 h 40 min against my estimate of 3–4 hours. I got it live that day with the empty-state layer above, then ran the browser test on all 14 pages, at 1440 px and 375 px, against production. If I did it again, we'd agree one schema between us before anyone drew a screen.
Communication
Two review calls with the owner, on 16 and 18 October, and a working call with his developer on the evening of the 16th. The final call included both. Every change went through a pull request with its own preview link, checked before it reached production.
At handover, the repository moved to the developer's GitHub account with a handover document, and the app now reads his database.
The agency later asked for the other half: a back office that runs every client, its own sales and its money. Read the Agency OS case study →
The client
"It all looks great. This is awesome. Yeah, this is it. This is great. It's exactly what I needed… the client side is pretty much done. That looks good. I don't think we need to do anything else for the clients."
Christian, agency founder · review call, 18 October 2026
Need this under your brand?
White-label, start to finish: I never contact your clients, and I'm happy to sign an NDA. I reply within 2 hours, whatever your time zone.