2 ms·
> Anyone who says to me "I'll just put everything in PostgreSQL and optimize later" sounds just as naive as the person who says "let's build for scalability bef
by SkyPuncher 3y ago
> Anyone who says to me "I'll just put everything in PostgreSQL and optimize later" sounds just as naive as the person who says "let's build for scalability before we have any customers". Both are giving themselves problems they don't need
Both are giving themselves problems, but they are fundamentally different decisions. I will almost always take the "optimize later" approach as there's not always a "later".
For most new products, the biggest challenge is finding product market fit. Once you have that, the world is your oyster. I will happily pay a 10% tax after PMF to be 10% better at finding PMF now.
If I've found PMF, I will have more revenue, more traction, more budget, etc to fix the problems I created. If I don't have PMF, everything goes in the trash.
- adamnemecek 3y agoIt's not 10% though, is it.
- SkyPuncher 3y ago10% was just a smallish number. In my experience, it's actually less than 1%. Code typically follows one of two paths: * It's in an unused/underused part of the app. Performance doesn't really matter. * It's in a highly used part of the app. Performance matters, but you'll never be able to predict the features that get layered on top of it. Fix performance as you build those new features.
- Waterluvian 3y agoThis is my experience. Get it out there, learn what you don’t yet know about the problem/product space, then improve and optimize. The hard parts, in my experience, are being sufficiently seasoned to know what parts are hard to do later and are worth facing up front, and making sure the decision makers buy into this so you’re not blindsided by the classic “there’s no time for tech debt.”