It's not so much requirements changing as simply the timeframe for implementation. As I work at WePay (with the author of the post), I can at least comment on our specific growth needs:
* UI. As your customer base grows (along with your company's reputation), the overall expectation of a quality product grows with it. Bugs that are a minor irritation for some people are dealbreakers for others, especially when you're taking on an industry giant - so minor problems make you lose customers (often permanently, given the "tried them three years ago, buggy, will not come back" attitude of most people). We're taking on PayPal - which, while not exactly known for a quality user experience, is extremely stable. We found this problem increased by at least an order of magnitude when we launched our stores product.
* Testing. Front and back-end. Like above, growth = reputation = expectation of quality. Gotta keep things stable, and there are some things that have absolutely zero margin for error (I've spent three days to produce a three-line patch, simply because I had to be aware of and handle dozens of different scenarios, and making an error could result in the wrong amount of money ending up in an account. Yes, it worked correctly)
* Support. If you're dealing with people's money, it's kind of a big deal. I'll let you use your imagination.
* Fraud. A non-trivial portion of our payment review involves human screening. With a couple hundred payments per day, that's manageable. Hundreds or thousands per hour? Not so much. We have to make smarter automated rules to avoid human screening where possible, and improve the UX in our back-end review panels so that humans can make intelligent decisions faster where necessary. Good code can replace (or free up, or avoid the need for) several human reviewers, and good human reviewers are just as hard to hire as good programmers. This and support are currently our tightest bottlenecks, since they directly limit the number of payments we can process in a day.
* UX. Not so much "is it pretty", but "does it do what I want?", "will I use it again?", etc. A huge percentage of our user base is virally acquired (ex. someone who previously made a donation comes back and sets up his own donation campaign and starts collecting money), which costs us nothing. The more we can entice users to stay engaged or engage their friends, the faster we can grow. If we can turn a payment receipt into a customer acquisition medium (customer meaning person collecting money, not paying), that's more users at effectively no cost to us.
* Scaling (in the traditional code sense). Not just server load, but weird problems that simply don't happen except at volume - database row locking, update collisions, etc. Detecting and fixing those types of problems is much harder than most people would think.
* Sales + Marketing. Not only expanding your markets, but making sure that as you're spending more on those efforts that your spending is effective. Have you saturated a tiny niche? You need more niches, and bigger groups to go after.
* Compliance and legal stuff. Did you know that as your annual payment volume increases, you have to adhere to stricter security guidelines for PCI compliance? While we've always held ourselves above and beyond the strictest guidelines, you still have to deal with compliance audits and such that don't happen at lower payment volume.
* Analytics and metrics. We're past the point where we can randomly guess at what's working and what's not. While we don't hold ourselves up with internal red tape and politics, we do actually need to measure the efficacy of the changes we're making. It's no longer a single new customer bumping the graphs by 20%, so we need pretty fine-grained measurements for this kind of thing (thankfully, we have enough volume where we don't need to let stuff sit in production for weeks to get a statistically significant sample size)
There's plenty more than that - most is quite general, though some is very specific to our company (fraud, in particular), and obviously not all of it is specific to engineering. My day-to-day is around payment stability and related back-end services, which also includes fraud management and our admin panel. Working 50+ hour weeks - quite a bit less intense than the 80+ I did during YC, but actually sustainable - simply doesn't allot me enough bandwidth to do everything that I need to do (I'm only commenting because the original post is a thinly veiled recruiting attempt and I've got desks that need filling). I have to solve problems like "an API call to a credit card processor timed out, how can I resume this automatically in a way where I know we will not accidentally charge a card twice" and "what changes do I need to make to ensure that a data integrity check never fails?" while at the same time architecting data models for new features, interviewing developer candidates, refactoring old systems for reliability and future-proofing, and providing our support team tools that allow them to do their job but don't allow them access to sensitive information (see again: PCI regulations). And I don't even touch the front end anymore.
Obviously, we're hiring. wepay.com/jobs :)