When I talk to someone about a project that has the potential to be big, they always are concerned about scaling. Analytics platforms are a perfect example -- there's going to be so much data logged that you want to plan for it. Right?

Yes, but not the way you think.

When modern software scales, it doesn't just completely break. It gets slow first. The truth is that any new software built by professional engineers today is almost always going to give you lots of advance warning when it starts to slow down, and you'll have time to deal with it. There are going to be a lot of developers who will get mad at me for saying this, and they'll come up with anecdotes as to why I'm wrong. 

Their problem is that they're not thinking about a business, they're thinking about a piece of software in isolation. They're not thinking of the changes in software development practices that have happened in recent years. Between automated test coverage, monitoring, app analytics, cloud-based architectures, and the other coding tools we have to work with now, scaling isn't the problem it used to be. This is 2013 -- premature over-building and over-spending will kill a company more often than technical scaling issues.

We built on an analytics project from the ground up, and early on, we knew the main way it needed to scale, so we built for it, and we nailed it.

One night, the founder coded his own widget that hit the API (he wasn't even a programmer but the API was easy to build on top of). The thing was, it hit a feature on the platform that used to be minor and wasn't built to scale. Performance took a hit until we were able to make changes.  Pesky, self-motivated founder! ;)

And you might be thinking "well see, you should have built the whole thing to scale, otherwise you wouldn't hit that point where the service suffered".

While that's true, it's not the whole story. The important thing to realize is that these changes only took us a few days to make, and everything was fine. The platform was about 4-5 months old at that point.  If we had tried to build everything to scale early on, it could have easily taken a year for the business to get to the same point, so they would have had to spend lots more money and made customers wait longer to sign up and give them money! (For the record -- this story is years old, and the company in question is still around.)

Saying "I want to make sure it'll scale no matter what" is like telling an engineer "Take my money. And my house. And my dog." Soon you sound like a bad country song.

If you don't have big numbers of usage right away, scaling is almost always something you should ignore until the engineers tell you it matters.

If you're talking about a company that has +30 million uniques, and you're about to turn on a new feature -- they're going to speak up.

If you're a new company that's going to build a customer base from the ground up, get a team who knows how to scale, but have them start small initially, and then scale when the time is right. It's the ace up your sleeve -- you don't play it in the first hand of the game. You play it when the time is right.