You could think of building a scalable back end you don't actually need as a form of premature optimization, and I think the way around that is to evaluate & measure what you actually need - problems you have now, not problems you might have later (no matter how sure you are). @gerlv's suggestion to "Ship daily" is great because it not only forces you to ship often, so you feel like you're getting something done, it also forces to you evaluate what you need, and forces you to quickly get feedback from users that should be the true driver of what you need. (Assuming you want users, rather than a finished side project just for you.)
Michael Abrash has some books on optimizing code in assembly language, and he takes special care to talk about why & when to optimize that would also apply here. The point he makes repeatedly is to optimize from the user's point of view - don't do something the user won't notice.
http://www.phatcode.net/res/224/files/html/ch01/01-01.html#H...
We all do it though, this is a human trait, but we programmers and computer scientists often amplify the problem. We love obsessing over what's "best", without regard to whether we actually need the best. We are taught during our Computer Science degrees to generalize and abstract at every opportunity, to plan for future problems we might have, and for future problems others have had that we might never have. We discuss incessantly how important it is for software to be scalable, and how to use the "best" everything, best language, best database, best algorithm, etc.
Strive to solve only the problems you're already personally experiencing, wait to solve problems until you are already experiencing pain, and ignore the problems that only "might" happen, then it will be easier to finish things.