Context
I built a project called “Jmail”—a Gmail-style interface to browse a large dataset (the Epstein files).
It wasn’t meant to be huge. Just a useful interface.
I deployed it on Vercel because it was easy. One-click deploy. No infra headaches.
What Happened
At first, everything was quiet.
A few users. Some traffic. Nothing unusual.
Then it got shared.
And kept getting shared.
Reddit picked it up. Twitter picked it up. Media started linking it.
Traffic exploded overnight.
Hundreds of thousands of users. Then millions of requests.
And that’s when things started breaking.
- Pages slowed down.
- Cold starts piled up.
- Server-side rendering kicked in for every request.
Every single page view was hitting the server.
CPU usage spiked.
Costs… skyrocketed.
I opened the dashboard and couldn’t believe what I was seeing.
Tens of thousands of dollars.
For a side project.
People on Reddit started roasting the setup:
“Why on earth… using SSR for this?”
“Vercel… overpriced AWS wrapper”
Some even said:
“Should’ve been a static site.”
And the worst part?
They were right.
This should never have been server-rendered at scale.
Root Cause
Used server-side rendering (SSR) for content that could be static
No caching strategy for high-traffic workloads
Underestimated cost scaling on serverless infra
Impact
~$46,000+ infrastructure bill
Performance degradation under load
Public criticism from dev community
Emergency rethinking of architecture
Fix
Moved toward static generation and caching
Reduced server-side computation per request
Optimized infra usage
Lessons Learned
- Serverless costs scale brutally with traffic
- SSR is dangerous at scale if misused
- Going viral is an infra problem, not just a growth win
- Easy deployment platforms hide complexity
Prevention
- Use static generation wherever possible
- Implement aggressive caching (CDN-first mindset)
- Load test before going viral (assume success)
- Understand pricing models deeply before scaling
