#00 Report from a "founder" at 21: first product, first dumb decisions

I'm building my first product that real people are already using. I'm not going to talk about it here yet, because we're wrapping up the last piece before opening it to the general public. For now, we're running with test users only, to find bottlenecks and improve the experience.

The point of this report is something I've been learning while building this app: keep it simple and learn how to make decisions. I don't know if it's just me — tell me in the comments if it happens to you too — but it seems like our brain can't look at a microservices architecture or a scalable system design without wanting to apply it to every project.

The cache I didn't need

Last week it happened to me. There's a piece of data in the app that gets read all the time and changed almost never. I wanted to implement caching no matter what. I had already sketched out the whole flow.

Then I went and looked at the numbers. Given how many people will use the product over the next six months, what I already had was enough. Adding a cache there wasn't going to change anything at all for the user. It would only add one more service for me to maintain and one more unnecessary cost for the current context.

And that's the tip that comes before all the others: look at the data. Without numbers, I would have followed my intuition.

Every trade-off has an owner, and sometimes it isn't you

I've been studying a lot of System Design over the past few months, and what has helped me the most right now, putting it into practice, is analyzing the trade-offs of each choice — whether it's technology or the way I handle a piece of data. There's always a trade-off. The thing is, often it won't affect you right now. Maybe never.

One way to figure out whether a concept makes sense in your context: find out why and in what situation it was created. Nobody invented caching thinking about speed in general. They invented it because the database was falling over from so many reads. If you don't have that volume, you're paying the price of a solution to a problem you don't have.

That doesn't mean you shouldn't study these things. I think you should. I'm talking about the moment when every decision costs money, and this one costs a lot — both in infrastructure and in time.

It goes way beyond code

And it goes way beyond code. It's what I tell everyone who asks me for an opinion about something in life: understand your context first. My opinion only gives you an option, and that option is only valid if your context looks like mine.

I want to do weekly reports about what I'm learning on this journey. Hope you enjoy them.