3 ms·

> However, it just made sense for me due to the simplified operations, and re-using most of the learnings from my full-time job. It has enabled me to move faste

> However, it just made sense for me due to the simplified operations, and re-using most of the learnings from my full-time job. It has enabled me to move faster in shipping customer-facing features. As someone who is mostly in the same boat as you, you have got a strong point in terms of favouring tricks you know best. The amount of code I have had to throwaway made me not want to invest in things that require lots of resources to run and maintain (in other words, things I'd not be comfortable with managing all by myself). I almost always default to managed and serverless products: This won't necessarily be a winning strategy for everyone to say the least as it brings its own complexity to the table. It is pragmatic; however (like you call out), to trade one set of complexities (one that I am comfortable with) for another.

amzans 6y ago
Hey that's great! I think everyone should do what works for them. Using a tool "just because" it worked for others, seems to be what often drives many decisions in this industry. For example, would you go for the 2,200+ microservice architecture from Uber[1] just because they say it solved all their problems? They probably have their reasons, and they are unlikely to be the same as everyone else. I know my stack as a solo founder is unconventional, but it's what has worked best for me. And I'm happy with my choice. If serverless does the trick for you, then focus on that, and keep building the features that your customers actually care about. [1] https://eng.uber.com/microservice-architecture https://eng.uber.com/microservice-architecture