TLDR: Deleted my local Email Bits repo. No remote backup. Spent a weekend extracting and reconstructing the full codebase from deployed Lambda zip files, minified S3 frontend bundles, and CloudFormation stack configs. It worked. Here’s how.

The Mistake

It was one of those moments. A late-night cleanup session — moving folders around, making space — and at some point I ran the wrong rm -rf. The Email Bits directory was gone. That’s fine, I thought, I’ll just pull from the remote. Except I had never pushed to a remote. The repo only lived on my machine.

A truly excellent failure mode.

Email Bits is a CodePen-inspired platform for creating, editing, and sharing HTML email templates — 130+ hand-coded blocks, 35+ full templates, AI-assisted editing. Months of work. And it was still running on AWS. The deployed artifacts were out there. I just needed to get them back.

What’s Actually on AWS

The stack is React + Node on AWS, deployed via SST Ion — the same pattern I used on In Short Pod. That means at a minimum:

• S3 — the built React frontend (minified, bundled JS/CSS)
• Lambda functions — the backend API (esbuild-bundled Node.js)
• CloudFront — CDN in front of S3
• CloudFormation — the full infrastructure definition SST generates
• Supabase — database still fully intact with all schemas and data

The app was alive. The code was compiled, minified, and scattered across AWS services — but it was all there.

Step 1: Pull the Lambda Zip Files

The most recoverable piece. Each Lambda function has a deployment package you can download directly from the AWS console or CLI:

aws lambda get-function --function-name emailbits-api-handler \
  --query 'Code.Location' --output text

That returns a pre-signed S3 URL. Download it, unzip it, and you’ll find your bundled handler files. esbuild produces a single-file output per function — so each zip had one index.js file that contained all the business logic for that function.

The beautiful thing about esbuild bundles: they’re readable. No obfuscation. Variable names stay intact. Running the output through prettier gave me back something surprisingly close to the original source.

unzip function.zip
npx prettier --write index.js

Within a couple hours I had all the backend logic reconstructed — routes, database calls, template processing — basically clean.

Step 2: Extract the Frontend from S3

This was messier. The React frontend in S3 was webpack-bundled and minified — variable names mangled, structure flattened. You could see everything, but understanding it was another problem.

The process:

1. aws s3 sync s3://emailbits-frontend ./recovered-frontend
2. Identify the main chunk files (largest JS files)
3. Run through a beautifier to at least get readable formatting
4. Pull every feature-related blog post I’d written about Email Bits
5. Feed those posts + chunks of the minified bundle to Claude, asking it to reconstruct what the original component looked like

That last step was the real unlock. The blog posts were essentially a spec — they described features, flows, and UI decisions in enough detail that Claude could match them against the minified bundle and produce surprisingly clean reconstructed components. It’s not magic, it’s context. Give an AI enough information about what something should do and a garbled version of the code that does it, and it can close the gap.

Step 3: Reconstruct the Infrastructure

SST Ion generates CloudFormation stacks, and those stacks are a surprisingly detailed map of your infrastructure. I pulled them with:

aws cloudformation get-template --stack-name emailbits-production

This gave me back every Lambda config (memory, timeout, environment variables), the CloudFront distribution settings, the S3 bucket policies — basically the entire sst.config.ts reconstructed as a CloudFormation template. From there, working backwards to the SST config was mostly mechanical.

Step 4: Recover the Data Model via Supabase MCP

This was the easiest part. Email Bits runs on Supabase, and Supabase was never deleted — the data was intact. Using the Supabase MCP connector, I could query the live database schema directly from Claude:

• Every table definition, column type, and constraint
• All relationships and foreign keys
• Row-level security policies
• Indexes and views

A database that’s still running is basically a perfect schema backup. Combined with the Lambda code that queried it, the full data model came back in minutes.

What Was Actually Lost

Honestly? Not much that mattered:

• Comments — gone. The bundled output has no comments.
• Type definitions — I was using TypeScript, those are erased at compile time.
• Git history — completely gone. No commits, no blame, no rollback.
• Test files — not deployed, so not recoverable.
• Dev tooling config — tsconfig.json, .eslintrc, etc. Had to recreate from scratch.

The business logic, the data models, the infrastructure config, the component structure — all recoverable with some effort.

What I’d Do Differently

This one is obvious in retrospect: always push to a remote immediately. Not when the project is “ready,” not when it’s “cleaned up enough” — immediately, even if the first commit is just init. A private GitHub repo is free and takes 30 seconds to set up.

The second thing: source maps. I had disabled source map generation for the production build. If I’d kept them (even uploaded them privately to S3), the recovery would have been trivial.

And third: automated backups. For anything deployed to AWS, a simple cron job that zips and uploads your Lambda source or syncs your S3 frontend assets to a backup bucket costs pennies and would have saved me a weekend.

The Silver Lining

Rebuilding from compiled artifacts forced me to look at Email Bits from the outside in — the same way a user or a third-party developer would. I noticed places where the API surface was unnecessarily complex, where components had grown too large, and where I’d taken shortcuts that made the code fragile.

The reconstructed version of Email Bits is actually cleaner than the original. Sometimes losing your code is the code review you didn’t know you needed.

If you’ve done something similar or have a better recovery workflow, I’d love to hear about it. And if you want to check out what I rebuilt, Email Bits is live at emailbits.co.