4
5 Comments

How to choose the right parts for your technical stack?

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

on July 25, 2020
  1. 1

    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.

    1. 2

      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 ??

      1. 1

        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?

        • What are the skills of the team? Frontend, backend? It's best when people can work with their best expertise.
        • What languages, libraries, and frameworks are they familiar with?
        • How hard it is to teach people into this stack?

        Most stacks will scale well enough if optimized properly, so I always try to choose the path of least pain.

        1. 1

          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 :

          • how to deliver value rapidly
          • how to make it easier for the team to work with the stack
            And asking the right questions gets you in that mental state
          1. 1

            That's basically It, hope you find It useful.

            Good luck with your product!