Most likely, the things you want to pay attention to are:
- your caching tier,
- your database tier,
- your general architecture's design (if it's not designed to scale, it just won't).
Words of caution about the resources below:
- Some are generic resources, others are specific to one stack or language but still provide insight on the types of issues to deal with and how to (try to) address or mitigate them.
- Some provide general information of scalability.
- Some give only hints on basic pipeline and programming optimizations.
- Some are sponsored or hosted by industry-actors, in which case conclusions and comparisons may or may not be accurate and/or impartial.
Some papers' links may be unaccessible for you if you don't have a subscription to some publication networks.
Articles, Blogs and Web Resources
Famous Last Words
While I can understand your original intuition that you should bury some projects out of fear that they won't adapt well and survive, I think that's the wrong approach. While the "build it and they will come" approach can be wrong, the "build it only once it's perfect" counter-part can be just as wrong.
You don't know if your projects will reach the critical mass where they actually need to care about these issues, so why not build them anyways?
Maybe you'll fail at first, but then you'll have learned and your next product will fare better. It's better to try it this way than to one day really have to dive in the deep end of the pool without a net, for a real product. So go ahead and give these ideas a chance.
While it's true that it's hard to make an application scalable when it hasn't been originalyl designed to be, at least you'll have an application that needs to be modified for scalability. In my book it's better than no application at all.