This really depends heavily on how your frontend servers distribute load. If it's not designed to have extra capacity added to it at the flip of a switch (or maybe better yet, automatically when a sustained spike is detected), then planning for this sort of thing is tough.
If you design your load balancing in such a way that you can flip on extra servers in a matter of minutes (e.g. via AWS), then you'll only pay for the extra capacity while you're using it. You'll have to do some pricing research with some kind of scenario to see if the pricing works out.
HOWEVER if you have a sudden traffic spike due to popularity, there are worse things in the world than going down for a brief period, unless you're running life support systems or something.
If your app/startup/project is especially cost sensitive, then I'd suggest building what you need, and keeping it at that. If it explodes in popularity and you have to spend a couple of days adding capacity, you'd call that a good problem to have.
Furthermore, planning too far ahead for capacity you don't yet need will cause you to spend money now that you could spend on more critical resources.
As just one example, the first StackExchange Site (StackOverflow) ran on a single server until maybe last year, I believe. Jeff Atwood talks about it in his blog, and they were getting millions of pageviews/day before they added additional infrastructure to scale out for the StackExchange network.