Case Study

Full-stack SaaS · designed + built solo · live

Full-site screenshots, one ZIP.

Paste a URL, pick the pages you want, and TotumSnap hands you a named ZIP of full-page screenshots, so a redesign doesn't start with two hours of manual capturing. I designed the brand and product, then built and shipped the whole thing, code and all.

Next.js · Playwright · Supabase · Stripe

3 weeksBuilt solo, nights and weekends
Full-stackCrawl, capture, billing, auth
Livetotumsnap.com
RoleDesign and engineering, end to end
TimelineNights and weekends, roughly 3 weeks
Year2026
StatusLive · totumsnap.com

Built with

Next.js · App RouterPlaywright workerDocker on RailwaySupabase · Postgres and StorageClerk · authStripe · subscriptionsVercelCursor and Claude Code

Every redesign starts the same way. Someone manually screenshots 30 to 40 pages of a site so the team has reference material. It's tedious, slow, and exactly the kind of task that shouldn't exist anymore. So I built the tool I kept wishing I had. Paste a URL, it crawls the site, you pick the pages that matter, and it returns full-page PNGs named by URL path, zipped and ready.

Manual screenshot workflow before TotumSnap
Before — Messy Long Names
TotumSnap automated crawl and capture
After — Short Clean Structure

I didn't hand this to engineers. I designed it and built it.

The pipeline: a crawl job discovers a site's pages, the user selects which to capture, a Playwright worker visits each page and renders a full-page screenshot, and an archiver bundles them into a ZIP uploaded to Supabase Storage. The frontend polls job status throughout.

The hard parts: cookie-consent banners ruin screenshots, so I built suppression that works across Cookiebot, OneTrust, Osano, and most major consent platforms. Bot-blocking, timeouts, and near-duplicate pages each needed handling. The single hardest part was getting Chromium to behave reliably inside a Railway Docker container.

AI as a capability, not a crutch: Cursor for the frontend, Claude Code for the backend and worker. The judgment (architecture, scope, what to build and what to cut) was mine. The tools made a solo full-stack build possible in three weeks of nights and weekends.

I assumed there would be one solution that could capture any site's pages. There isn't. In the rush to ship fast, I had to stop and re-evaluate. No two sites are built the same. Some have animations that load slowly, some have pop-up blockers, some run headless, and all of it broke the capture. So I built the crawl to account for it: delaying capture to let animations finish, looking past cookie pop-ups, and flagging the cases where a site's own security blocks the crawl no matter what. That last part became a user-facing memo. When a capture fails for that reason, the app tells you it's the site, not TotumSnap.

Then there were the self-inflicted failures. A committed node_modules directory, TypeScript compiling in the wrong scope, a browser install at the wrong stage. Each one fixable, each one a few hours I hadn't budgeted. Building solo means every mistake is yours to find and yours to fix.

TotumSnap user-facing capture failure memo
TotumSnap error state when a site blocks the crawl

Better handling of sites that block crawlers, smarter detection of near-duplicate pages (pagination, filtered views), configurable mobile viewports alongside desktop, and a team feature for agencies with shared job history and client-facing download links.