In this guide
Launch day, 11:40 a.m.
The invitation went out at nine. By eleven, thirty-one people have signed up. Then the replies start: "I never got the sign-in link." "Is the site down?" Your logs show every email was requested. The email service sent the first hundred of the day and refused the rest.
Nothing broke. A free plan did exactly what its pricing page said it would. You just never counted your launch.
Free plans are sized for normal days. Launch day isn't normal: dozens of people sign up within hours, each one triggers a chain of emails, and you deploy fixes far more often than usual. This guide shows how to count a launch before it happens, which limits break first, and what to upgrade, and when.
Before launch day
- The most common launch-day failure is the daily email cap: 100 a day on a typical free email plan.
- Second come hosting allowances (deploys count) and database pausing in the quiet week before launch.
- Do the count a week before. Upgrading takes minutes when nobody is waiting.
Why launch day is different
Three things happen on launch day that don't happen on a normal day, all at once:
- Bursts of new users. Most sign-ups arrive within a few hours of your announcement. Every new user triggers more activity than an existing one.
- Retries. People who don't get an email right away request another. People who hit an error refresh. Each retry is more load on exactly the thing that's struggling.
- More deploys. Real users find real bugs. You fix them quickly, and each fix is a deploy.
Free plans fail on one of these, rarely on overall traffic.
Count your launch-day emails
Start with the number of people you'll invite, then count every email one new user causes in their first hour.
Hypothetical example
Forty new users means about 200 emails. If your product emails other people on the user's behalf (reminders to their clients, invitations to teammates), multiply again: a user who invites five clients causes five more emails immediately.
| New users on launch day | Emails (5 each) | With 5 invitations each |
|---|---|---|
| 20 | 100 | 200 |
| 40 | 200 | 400 |
| 100 | 500 | 1,000 |
A typical free email plan allows 3,000 emails a month but only 100 a day[1]. Twenty new users already reaches the cap. The first paid tier, at $20 a month, raises the allowance to 50,000 a month and removes the daily cap[1].
Count your deploys
Some hosts now measure free usage in a single allowance that deploys draw from. On Netlify's free plan you get 300 credits a month, and each production deploy costs 15 of them[2]. Twenty deploys would use the whole allowance before any traffic is counted. When a site reaches its limit, it pauses until the next billing cycle, and every project on the account pauses with it[2].
Hypothetical example
| Week | Deploys | Credits used by deploys alone |
|---|---|---|
| A normal week | 2 | 30 |
| The week before launch | 6 | 90 |
| Launch week | 15 | 225 |
Add traffic and server functions on top, and launch week alone can use most of a free month. Netlify's Personal plan at $9 gives 1,000 credits; Pro at $20 starts at 3,000[2].
Other hosts limit you differently. Vercel's Hobby plan has generous technical limits but is restricted to non-commercial, personal use[4], so a product you charge for belongs on Pro regardless of traffic. Cloudflare's free Workers plan allows 100,000 requests a day[6], which a small launch rarely reaches, but a request loop bug can.
The database that went to sleep
This one usually strikes in the week before launch. Supabase's free projects pause after one week of inactivity[3]. If you finish building, go quiet for ten days while you write your launch post, then send invitations, the first visitors can meet a paused project.
Neon behaves differently: its free compute sleeps after five minutes idle but wakes automatically on the next query, usually in a few hundred milliseconds; it suspends only if you use up the month's compute-hours or transfer[5]. You'll see a slower first request, not an outage.
The simplest fix is to move to a paid database plan before launch: Supabase Pro starts at $25 a month with no pausing[3]. It also gets you daily backups, which matter the moment real customers' data is in there.
The quieter limits
| Limit | What it looks like on launch day | How likely for a small launch |
|---|---|---|
| Database egress | Slow or failing queries if you serve files from the database | Low, unless you store media |
| Concurrent builds | A fix waits behind another build | Medium, annoying rather than breaking |
| Login monthly users | New sign-ups blocked | Very low: free tiers allow tens of thousands |
| Function timeouts | Slow tasks fail under load | Medium for PDF, image or AI tasks |
A week before launch
Your seven-day checklist
- Count launch-day emails with the table above and your real invitation number. Near 100? Upgrade email now.
- Read your hosting plan's terms for "commercial" and "personal". Charging money? Move to a paid plan.
- Estimate launch-week deploys and check how your host counts them.
- Wake the database and decide whether it'll be on a paid plan by launch day.
- Turn on usage alerts at 50% and 80%, sent to an inbox you read.
- Do a full test sign-up from a fresh email address the day before, through to the first notification.
For the full week, day by day, see the launch week plan.
What upgrading early costs
Compare that with a launch where a quarter of sign-ups never get their sign-in link. Those are people who heard about you once, tried once, and left. You can't buy that first impression back.
Free is enough vs paid earns its place
Free can carry a launch when
- You're inviting fewer than about 15 people
- Your product sends few emails per user
- You're not charging yet, and your host allows that
Upgrade before launch when
- Your email count is anywhere near 100 a day
- Your database could have paused in a quiet week
- You're charging on a plan that excludes commercial use
- Launch week deploys could exhaust the month
Questions
Can I stagger invitations instead of upgrading?
Yes, and it's a good idea anyway: inviting in batches of 15–20 over a few days keeps you under daily caps and gives you time to fix problems between batches. The trade-off is less of a launch-day moment.
What if I'm already at the limit on launch day?
Upgrade immediately. Most email and hosting upgrades take effect within minutes. Then resend sign-in links to everyone who signed up in the last few hours.
Will I be stuck paying after launch?
Most first paid tiers are monthly with no long contract. But once you have paying customers, you'll want to stay: the reasons you upgraded don't go away.
Put your real numbers into the email table: how many people you'll invite and what one new user triggers. If the answer is near 100, upgrade today. Then check every other tool in Free plans, mapped, and make sure the emails you do send arrive: Why your emails land in spam.
What builders are saying
Real public threads on this topic, so you can hear it from people who hit these limits themselves. Summaries are ours; follow the link for the full discussion.
Sources
Checked 14 November 2026. Numbers in brackets in the text point to these sources.
