As a technical leader Looking to reduce technical burdens later on when your project grows, how you approach choosing the right dev tools taking into consideration future scaling, costs, and complexity.
Looking for practical advice or a methodology that we can apply and ideally, it would be nice if shared with stories of products you worked on.
Thank's for all for contributing to IH, I personally learned a lot reading stories here <3
Unless your product/idea will have really low margins, I don't think you should care about scaling and complexity for now.
Scaling is a really good problem to have, it means people are using it and you are getting money. Scale later.
Time is a very valuable resource, so when choosing my stack I choose comfort and speed of development, so I can ship my idea faster and start validating. Choose whatever stack you're good on imo.
I fully agree with your statements, at least for the first steps is more important to worry about idea validation instead of scaling.
In my case am managing a small technical team and I find choosing the right approach to doing stuff is kinda perplexing.
We are trying to make use of open-source/free solutions or even paid ones in some cases so that we can deliver value rapidly, but also we are trying to make sure that we build wrappers around third parties so that switching to a more convenient solution in the future wouldn't cause us so much debt any thoughts on this approach is it worth the effort ??
Which stack are you planning to use?
Creating wrappers around libraries can be good as you said, but don't go too far trying to generalizing everything trying to predict problems. In my experience, it's really hard to predict what problems will arise, so generalizing can be a waste of time.
Another thing is that if the library is popular enough chances are developers will be familiar with the API, having a wrapper is another layer of knowledge necessary to get into the project.
I had this exact problem once, and my decision was based on these questions?
Most stacks will scale well enough if optimized properly, so I always try to choose the path of least pain.
Thank you for your time, It was a good exchange a different perspective tbh.
To resume your ideas and correct me if I made a mistake we need to adopt a more team-centric approach rather then getting so deep into the technical issues, we need to concentrate on :
And asking the right questions gets you in that mental state
That's basically It, hope you find It useful.
Good luck with your product!