What does it take to run a web app with 5K – 10K users?

That's not a very meaningful metric on its own. 5K users per day? Per month?

How's the distribution of traffic? Do people use it spread out over the month or mainly within the last or first days of the month? Do they use it on work days or throughout the week? Are they from different time zones?

What do they do? Is there a lot of write activity or is it mainly read? Is the read stuff cacheable between users or is it highly individualised. etc. etc. etc.

I think you're asking a capacity planning question. To the extent that you're asking a capacity planning question, for most apps in the Rails sweet spot (CRUD which takes data from users, munges it, and stores it in the database, perhaps interacting with a few external APIs and making occasional use of more advanced things like e.g. taking uploads and storing them in S3 prior to processing by queue workers), you're going to not even notice the day that your user count hits 10k.

If you back out the numbers, they go something like this: eight hour work day, worst hour has 25% of the user base actively logged in (we'll assume it is a very sticky app), 10 significant actions per hour implies 25k or so HTTP requests which actually hit Rails, which is less than 8 requests a second. You can, trivially, serve that off of a VPS with ~2 GB of RAM and still have enough capacity to tolerate spikes/growth.

Let's talk about the more interesting aspects of this question, which aren't mostly about capacity planning:

Monitoring: Depending on what you're doing, at some point between 0 users and 10k users, the app failing for long periods of time starts to seriously ruin peoples' days. Principally, yours. Depending on what you're doing, "long periods" can be anything from "hours" in the general case to "tens of minutes" for reasonably mission-critical B2B SaaS used in an office to "seconds" for something which could e.g. disable a customer's website if it is down (e.g. malfunctioning analytics software).

I run a business where 15 seconds of downtime means a suite of automated and semi-automated systems go into red alert mode and my phone starts blowing up. I don't do this because I love getting woken up at 4 AM in the morning, but because I hate checking my inbox at 9:30 AM in the morning and realizing that I've severely inconvenienced several hundred people.

You're going to want to build/borrow/buy sufficient reliability for whatever problem domain it is you're addressing. I wouldn't advise doing anything which requires Google-level ops skills for your first rodeo. (There is a lot to be said for making one's first business something like a WordPress plugin or ebook or whatnot where your site being down doesn't inconvenience existing customers. That way, unexpected technical issues or a SSL certificate expiring or hosting problems or what have you only cost you a fraction of a day's sales. Early on that is likely negligible. When an outage can both cost you new sales/signups and also be an emergency for 100% of your existing customer base, you have to seriously up your game with regards to reliability.)

Customer support:

Again, depending on exactly what you're doing, you will fail well in advance of your server failing on the road from 0 to 10k users. Immature apps tend to have worse support burdens than mature apps, for all the obvious reasons, and us geeks often make choices which pessimize for the ease of doing customer support.

My first business produced a tolerable rate of support requests, particularly as I got better about eliminating the things which were causing them, but I eventually burned out on it. I have a pretty good idea of what my second one would look like if it had 10k customers -- that would imply on the order of 500 tickets a day, 100+ of them requiring 20 minutes or more of remediation time. This would not be sustainable as a solo founder. (Then again, if that business had 10k customers, revenues would presumably be in the tens of millions, so I'd have some options at that point. There are many businesses which would not be able to support a dedicated CS team on only 10k customers, like e.g. many apps businesses, so you'd have to spend substantial brainsweat on making sure the per-customer support burden matched your unit economics.)

The biggest issue: selling 10,000 accounts of a SaaS app is really freaking hard.

I can't speak for him, but the RSS reader I am working on at the moment is similarly split into multiple parts:

* Crawler - retrieves RSS feeds and parses articles

* Database server

* Analyser - performs semantic analysis and various other statistical processing on posts

* Propagator - pushes new posts to everyone's feed

* Cacher - serves a cached copy of the user's feed

* Web server

Based on loads I would just add more nodes depending on what was needed.

Pretty close :)

> I am now wondering what it takes to launch and successfully run a website with 5-10K users?

What do you mean by this? Doesn't this depend on the usage patterns? Do you have 5-10k concurrent users or are these users spread over a day?

The operations side is a whole other profession that dovetails into the technical aspects of getting it running on a good architecture.