How Speechify serves 500,000 dynamic pages to 60 million users on Vercel
Concept 1: The Problem with Dynamic Pages at Scale
What is a "dynamic page"?
A dynamic page is a webpage whose content is generated fresh each time someone visits it, often by reading from a database.
Why is this a problem?
Imagine a simple math:
- 500,000 pages
- Hundreds of thousands of visitors per day
- Each visit = a database read
1 visitor → 1 database read ✅ Fine
1,000 visitors → 1,000 database reads ⚠️ Getting heavy
100,000 visitors → 100,000 database reads 🔥 Expensive & slow
Why can't Speechify just use static pages?
Static pages are pre-built and don't change. But Speechify has:
- 10,000 base pages
- Translated into 40+ languages
- With constantly changing pricing experiments and funnels
Static generation simply can't keep up with content that changes this frequently.
Concept 2: The Solution — Caching Strategies (ISR + Data Cache)
What is Caching?
Caching means storing a copy of something so you don't have to rebuild it every time.
Think of it like a photocopy machine:
- First person asks for a document → you print it fresh
- Everyone after that → you hand them a photocopy instantly
Incremental Static Regeneration (ISR)
ISR is a Next.js feature that combines the best of dynamic and static:
Step 1: First visitor arrives
→ Page is generated dynamically (database is read)
→ Page is immediately CACHED
Step 2: Next 10,000 visitors arrive
→ They all get the CACHED version (no database reads)
→ Fast ⚡ and cheap 💰
Step 3: Content changes
→ Cache is invalidated
→ Next visitor triggers a fresh generation
→ Cycle repeats
Vercel's Data Cache
This works alongside ISR to cache database query results specifically, so even when a page regenerates, it may not need to hit the database again.
The Combined Result
Without caching: 100,000 visits = 100,000 database reads 💸
With ISR + Cache: 100,000 visits = maybe 5 database reads ✅
This is how Speechify serves 500,000 dynamic pages without infrastructure costs scaling with traffic.
Concept 3: Points of Presence (Global Edge Network)
What is a "Point of Presence"?
A Point of Presence (PoP) is a server location distributed around the world. When a user visits a page, they are served from the closest server to them.
User in Tokyo → Served from Asia server ⚡ Fast
User in London → Served from Europe server ⚡ Fast
User in New York → Served from US server ⚡ Fast
Why does this matter for Speechify?
Speechify serves 60 million users globally across 40+ languages. Without a global edge network:
- A user in Japan might be fetching data from a server in the US
- That adds hundreds of milliseconds of delay
- Multiplied across millions of users = poor experience
How it connects to caching
The cached pages are stored at each point of presence, not just one central server:
Page cached in US PoP → Fast for American users
Same page cached in EU PoP → Fast for European users
Same page cached in Asia PoP → Fast for Asian users
Concept 4: Auto-Scaling with Fluid Compute
What is the traditional scaling problem?
Traditionally, companies had to predict traffic and provision servers in advance:
Normal day: 1,000 visitors/hour → You need X servers
Viral moment: 100,000 visitors/hour → You need 100X servers
Problem: You either:
- Over-provision (pay for servers sitting idle) 💸
- Under-provision (site crashes under load) 💥
What is Fluid Compute?
Fluid Compute is Vercel's auto-scaling system. It automatically adjusts computing resources based on real-time demand:
Low traffic → Few resources used → Low cost
High traffic → More resources spin up → Handles the load
Traffic drops → Resources scale back → Cost drops again
The business impact for Speechify
This is directly why Speechify achieved a 50% cost reduction:
- They stopped paying for idle servers
- They stopped over-provisioning "just in case"
- They only pay for what they actually use
Concept 5: Instant Rollbacks — Shipping Safely at Scale
What is a "bad deploy"?
A deployment is when new code is pushed live to users. A bad deploy is when that new code has a bug or breaks something.
Why is this especially risky at Speechify's scale?
Small startup (1,000 users):
Bad deploy → 50 users affected → Annoying but manageable
Speechify (60 million users):
Bad deploy → Potentially millions affected → Revenue loss in minutes
What is an Instant Rollback?
An Instant Rollback means you can immediately revert to the previous working version of your site with a single click — before most users even notice.
Timeline WITHOUT Instant Rollback:
Deploy → Bug found → Developers scramble → Fix written →
Fix tested → Fix deployed → 2-4 hours of damage ❌
Timeline WITH Instant Rollback:
Deploy → Bug found → Click rollback →
Previous version restored in seconds ✅
The cultural shift this enables
Before: Teams deploy with dread ("what if something breaks?") After: Teams deploy with confidence ("we can fix it instantly")
This allows a small growth team to ship new funnels and A/B experiments every few days — a pace that would otherwise require a much larger engineering team.
Concept 6: Continuous Deployment & Removing Infrastructure Overhead
What is Continuous Deployment?
Continuous Deployment (CD) means every time a developer pushes code, it is automatically tested and deployed to production — no manual steps required.
Traditional workflow:
Write code → Manual testing → Manual build →
Manual deploy → Manual monitoring → 😓 Slow
Continuous Deployment:
Write code → Push → ✅ Automatically live
What overhead does this eliminate?
Speechify's growth team has no dedicated platform engineering function. That means they don't manage:
| Task | Who handles it? |
|---|---|
| Security patches | Applied automatically by Vercel |
| Scaling servers | Handled by Fluid Compute |
| Deployment pipelines | Managed by Vercel |
| Infrastructure monitoring | Built into the platform |
The competitive advantage
In AI, speed to market matters enormously:
Week 1: Idea conceived
Week 2: Code written
Week 3: Deployed to 60 million users ✅
vs.
Week 1: Idea conceived
Weeks 2-4: Infrastructure setup
Week 5: Code written
Weeks 6-7: Deployment pipeline configured
Week 8: Finally live ❌ (competitor already shipped it)
Summary: How All Concepts Connect
60 Million Users
↓
500,000 Dynamic Pages
↓
┌─────────────────────────────────────────┐
│ ISR + Data Cache │
│ → Render once, serve millions │
│ → Database reads minimized │
├─────────────────────────────────────────┤
│ Global Edge Network (PoPs) │
│ → Cached pages served from nearby │
│ → Fast for every user worldwide │
├─────────────────────────────────────────┤
│ Fluid Compute (Auto-scaling) │
│ → No over-provisioning │
│ → 50% cost reduction │
├─────────────────────────────────────────┤
│ Instant Rollbacks │
│ → Bad deploys fixed in seconds │
│ → Zero user impact │
├─────────────────────────────────────────┤
│ Continuous Deployment │
│ → Small team ships at massive scale │
│ → No infrastructure management needed │
└─────────────────────────────────────────┘
↓
Result: 99.99% uptime, 50% lower costs,
40x more pages, 3x larger audience
The core lesson: At massive scale, the right infrastructure doesn't just save money — it changes what a small team can accomplish and how fast they can move.