22
31 Comments

Choosing a Tech Stack - Do you just go with whatever you're comfortable with?

I just wrote a short Medium article, mostly to take a step back and look at my thoughts. How I Feel Choosing a Tech Stack in 2020. (TL;DR: It feels like falling down an ever increasing amount of rabbit holes and I end up doubting everything.)

Looking back, I come to the conclusion that your tech stack merely needs to be OK. If your thing encounters massive success, you can always refactor then.

The tech stack that makes the most sense for you is whatever you're most comfortable with right now.

Is this the philosophy you adopt?
Or do you have some kind of strategy?

  1. 10

    I have a strategy. I call it Engine vs Powerups.

    The "engine" is very core, broadly useful things you learn (or in this case do) that will help you not only now but over the long term. In terms of learning this would be things like mathematics, a foreign language, sales, writing, interpersonal skills, CS, etc, which will still be valuable in 50 years. In terms of your tech stack choices, this would mean technologies that will be easier to maintain, require fewer updates in the future and have a sufficient level of performance.

    In contrast, "power-ups" are extremely useful right now, but not so broadly applicable or evergreen. In terms of learning, this means things like the knowledge of the hottest social media growth channel of the moment, frequently changing JavaScript frameworks, popular 3rd-party tools and platforms (i.e. Firebase APIs, Auth0, various "back-end as a service" offerings, etc).

    Keep in mind, the "engine" vs "power-up" concept is more of a spectrum than a dichotomy. Learning a programming language, an OS or an open source protocol is somewhere in the middle. The knowledge is probably good for 5 years, but maybe not 30.

    The strategy I try to use is to spend most of my time working on the engine, but at key times when there's an opportunity, I go all-in on power-ups.

    Just doing the simplest thing that will work is great when building a new product. Using a language/stack you already know is great, too. But that's only half the story. The other half is long-term investment into building your skills. If you learn a new programming language every couple of years, and regularly build toy projects with emerging frameworks and tools then you'll have two advantages. You'll learn things from each language or framework that make you better with the others. You'll also have a better set of options to choose from when you do have an opportunity.

    1. 2

      I gave your podcast a listen and really enjoyed it. It's a great analogy that just might stick.
      Also, besides the content, you have a great voice!

  2. 4

    I don't disagree with most people here, but the primary reason for me focusing on high testability and super clean code (as well as a good tech stack from the beginning) is that I will lose motivation later, if my code ends up as a garbled mess.

    So much that I won't feel like refactoring, and it'll be easier for me to just rewrite the whole thing.

    I always seem to end in that situation.

    So this time, with Pull Dog and Dogger, I'm keeping it clean, although it might not be as fun to do always. Making yourself proud of your own work is quite important too.

    Oh, and people say that you can always refractor later. Sure, technically you can, but that doesn't mean you'll do it or that it will ever be a priority. And once you start building on top of a garbled mess, that mess gets even harder to clean up, because it now has dependencies.

    It's important to note that I'm talking about code quality here primarily. I still believe in the YAGNI principle and making the simplest and smallest thing possible that solves an issue. Just make that thing clean as well, for your own sanity. If the simple thing is clean, you can always build more complexity on top later. But if you're over engineering and it's a garbled mess, you might lose the love and motivation you have for the project.

    And lastly... Writing clean code is not necessarily slower if done right.

    1. 2

      I agree. It's awful forcing yourself to pile features to ugly code base :).

  3. 4

    I agree 100% with this. As an Indie Hacker, in particular, your goal is to turn an idea into a real product, solving a critical problem for a well-defined niche of customers who are willing to pay for a solution that fits into their workflow.

    Nowhere in this chain of requirements does your tech stack play more than a passing role.

    Your customers don't care how if the backend code is interpreted or compiled, they care that it performs well enough so that loading data from the database isn't noticeably slow.

    Your customers don't care if your frontend is built using state-of-the-art UI frameworks or jQuery 1.2 as long as it allows them to save time, save money, or make money.

    As developers, we're trained to think about the little things. We see edge cases, we see optimization opportunities, we feel pain when we imagine taking the less elegant way to solve a problem.

    Our customers see our tool as a way to spend more time with their kids. They see it as a means to make an impact in their lives.

    And honestly, I'd rather empower thousands of customers to make a difference by using a slightly wonky product than prematurely optimizing my backend performance expectations with imaginary usage data that I'll never be able to validate because all this planning and scheming keeps me from ever releasing said product :)

  4. 3

    Yes, I go with what I am comfortable with. There might be exception, but it has to be a single "component" of the stack. For example keeping Rails, but experimenting with new front-end framework. Never change everything at once!

  5. 3

    @FelDev I definitely agree. There are so many options now that builders and indie hackers can get too caught up in getting everything perfect before starting. Building out your MVP, getting customer feedback and iterating from there is definitely the way to go. Just ask @8bit. He knows all about building community first.

    1. 3

      technology is easy... community is hard.

      focus on the hard stuff first!

  6. 2

    I think opting for every new shiny object you find in the way is definitely a loosing strategy most of the time. Even more if they are not backed by the open source movement.

    Examples? Action Script, Flash, Google Reader... Every product that rely on the hold of a company is creating a perennial dependency and you will never be sure if company's interest will keep aligned.

    As for technologies, I keep seeing companies prospering using old and proven technologies like PHP, MySQL and server side rendering.

    I tend to use Ruby on Rails because it's really simple, does the job I need and cover things I don't even need to know. I think any mature open source framework is a good choice most of the time for most of the jobs.

    Also, we can be sure that the tech that has been for years, even decades will be with us for a time (Linux, Java...). But recency bias tend to make us think they all will be here for ever and there won't be technological debt.

    I prefer to make sure my stack will be well supported in the future.

  7. 2

    I would agree that what you're comfortable with now almost always the best option, but I'd caveat that by saying don't just build everything in your favourite language and stack just because you can.

    Sure you can implement auth*n yourself, you could do analytics yourself, but consider grabbing an off-the-shelf solution for these things if you can.

    If it's not the core part of what you're building, if it's cheap, easily replaceable, better than you could do in the time you're willing to spend on it, then use them.

    That's my starting point anyway, whether I can stick to it is another matter.

  8. 1

    There is a lot of new information and new ideas in the world every day. Already, all areas of activity have IT technologies. Conveniently, when there is an outstaffing company partner https://tech-stack.io/ with a full stack, with extensive experience in providing technology solutions to companies of all sizes, from startups to global corporations.

  9. 1

    It's a good idea to use whatever is easy to train for. Node, java, etc. Writing your own framework in ocaml or elixir might be fun but it wont add value to your customers.

  10. 1

    In my experience, there are two reasons to choose one stack over another.

    1. If it is a founder developing the product then go with what works for them.
    2. If it is hiring people or outsourced, then go with what the industry prefers.

    The only time it becomes an issue is when hiring developers, raising late-round funds, or looking to become acquired. Most likely, the stack will change later based upon numerous factors.

  11. 1

    I believe the choice is critical, can save you, or make you lose a lot of time. and maybe drive you to change some product requirements as you proceed.

    Every new project i start i try to go as far as i can before start coding, i usually follow the data, define its use cases, ask how it can be used outside the project, which parts are valuable than others, which parts will be growing faster..., that gives me hints about what database(s) to choose first.

    When i started working on my current project i did know that my data needs a graph structure, wasn't sure about the backend tech-stack yet, my first choice was ArangoDb, as i dug deeper, found out that i needed to use Foxx microservices, which made me uncomfortable since that will add another level of abstraction hence complexity i didn't need. After some examination, i decided to go with Dgraph, and that decision changed the backend choice.

    I was going for nodejs first with Arango, when i switched i needed to see what libraries are officially supported by the database, and found out that the best SDK is written in golang, so i switched to use gin framework for the backend, i wasn't familiar with golang, but i knew the resources available online can get me going fast.

    In the frontend i was also looking to handle offline mode and stream some metadata, i thought of pouchdb along with couchdb in the backend, but then more services means more things to worry about, so i decided to go with gundb, it's not data consistent but the data used are just cache data, it can be recovered, data consistency wasn't critical here.

    I also needed some high level of flexibility in the UI, i have used Angular, Vue and React in the past but i needed more, i needed a way to interact with components at runtime, and Svelte was perfect for my use case, since components are compiled, i can store them in a list and manipulate the props or add custom hooks anytime with plain js.
    For the CSS I went with TailwindCss, that's probably the only choice that was clear for me.

    In the DevOp department, i wanted some separation between Auth Service and Core API, so i needed an API Gateway to handle JWT verification and manage some headers. i went with KrakenD after trying few.

    To put them together i had to think of the cheapest way since i won't be publishing the solution anytime soon, i avoided Kubernetes due to the resources it requires, so i just went with Portainer for docker management and Traefik as a reverse proxy to handle SSL.

    I try to avoid no-code solutions, IDK it may work for you,
    Best of luck.

  12. 1

    100% the philosophy to adopt.

    The simple question I ask myself: "will my customers notice or even care which tech I'm using?"

    99.99% of the time the answer is "no." The only exception is when you're building new technology (e.g., inventing a new UI framework) or tools for developers.

    Use what you understand and what you can ship ideas with the fastest and worry about specific tech problems as they emerge. Most tech issues are a result of poorly organized/poorly optimized code or bad naming, not the tools you're using.

    A couple of things that have helped:

    1. Use patterns for your code so it's easier to migrate (i.e., always write UI components the same way, always write business logic the same way).
    2. Use a database schema (or something like GraphQL) to keep data consistent.
  13. 1

    If you are already a uber developer, like many commenting already, then going with what you already know seems to be the way to go.

    However, if you are a continual learner or new, then choosing a new tech stack might be the perfect excuse to learn something new and expand your skillset. So if your MVP fails you at least learned a new skill you can apply on a future project.

  14. 1

    I approach such things pragmatically. Ten years ago, I learned a single programming language that was the most widely used language for web application development at the time. Last year, however, I realized that new languages and frameworks have emerged, thanks to which I can program everything much faster and thus put it into production quickly and start testing. I think that nowadays, when new applications are being created every day, this is the most critical factor.

    In any case, I agree with the opinion that a person should stick to what he knows best so that he is not demotivated if he cannot program something that he has proved before.

    I stick to the idea that programming something is only 20% of success unless it is an application that is truly exceptional and the first of its kind. 80% is communication with potential users and clients. And this communication should start as soon as the full product is finished.

    My strategy:

    1. Create a landing page. Many people say it's useless, but I don't agree with that. Create a landing page is a perfect approach for the developer because it allows him to open up his mind and creativity in solving and defining the problem he is trying to solve. It will also force him to look for a similar solution on the market for inspiration, and this can save him a lot of time if he finds the answer he wanted to program.
    2. Getting feedback - this probably doesn't need comment. Feedback is essential in every phase of the project.
    3. Programming the core functions of the application - developers often think about all the details. Such reflection slows them down in what they want to do. Instead, it's a good idea to write down a list of application features and sort them by how important they are to the next stages of the project.
    4. Find complementary products and connect with them
    5. Communication, communication, communication, value, value, value, content, content, content. (sorry for spam :O)
  15. 1

    If your goal is to build an MVP, the best tech stack is the one you know. Full stop.

    If your goal is to learn something new, then sure, play around with the shiny new thing.

    But to create something and bring it to market quickly, you need to choose the tools with which you are most productive. There's enough friction in trying to launch something. You don't need the added friction of trying to learn something new as well.

    And when you get down to it, there's not much difference in what you can produce on the various stacks. Your product won't succeed or fail because you chose one tech over another.

    1. 1

      If your goal is to build an MVP, the best tech stack is the one you know. Full stop.

      100% this.

  16. 1

    For Indie Hacking, I go with the tech stack that gets me to market the fastest. I've done Spring Boot, Django, Ruby on Rails, Clojure, PHP and many other things. So far, Ruby on Rails keep on winning.

  17. 1

    Starting with a stack you're unfamiliar with is a terrible idea.

    • You aren't familiar and can't fix bugs quickly.
    • You have a ramp-up time to knowing where to begin building
    • Can't validate quick with a stack you don't understand
  18. 1

    I tend to stick with what I know, while at least playing around with other technologies to judge whether they are worth the switching cost. In most cases it isn't worth switching. React is the best example of a tech that was absolutely worth switching to because it was quickly apparent it would help me build better, more maintainable products. The transition from a fullstack framework was a bit painful at first (ugh webpack), but finally settled on Next.js, Firebase, and Vercel as a really productive combo.

    Lately I've been building a tool that helps people generate custom React codebases with their desired tech. My hope there is it enables people with one or two tech preferences to assemble all the rest without a huge learning curve.

  19. 1

    @arvidkahl tweeted about this the other day:
    Arvid: Most of the time, what you already know will be more than enough. If you know JavaScript, build with node/cue/react. If it’s PHP, go with Laravel.

    To which I replied:
    Wait, you mean you're not using the latest, greatest, sexiest language that only 1% of developers know making it a challenge to scale later on???
    Wait, you mean MVP means getting to market quickly without a delay to learn a sexy new language?
    </sarcasm>

    Being sarcastic obviously but I think the end point is valid. Ask any average user what Facebook is written in, what Twitter runs on, what Slack uses. No one knows are cares. Choose the tech that will get you to MVP as soon as possible so you can start getting user feedback. Revenue, users, and feedback are golden; choose language A over language B is worthless.

    1. 1

      Wait, you mean you're not using the latest, greatest, sexiest language that only 1% of developers know making it a challenge to scale later on???

      He did go with a relatively new language that under 1% of developer know and it was great for scalability.

      1. 1

        And while this worked out pretty well for me and FeedbackPanda, it added some friction to the actual sale of the business. After all, Elixir developers are much rarer than Node or PHP devs, and finding a replacement for me as the foundational (and only) developer of the whole software stack was slightly more challenging than it would have been due to this scarcity.

        On the other hand, all the candidates we had for the role were excellent, so maybe Elixir devs compensate their rarity with very impressive skill levels.

        In retrospect, I could have built the platform on a Node-based stack (which I am also quite fluent in), and it would have worked comparatively well, performance-wise.

        My main motivation was to get going quickly. I had learned Elixir just a few years before I started FeeddbackPanda, and it was the most recent language I was comfortable with. Turned out THAT was a good choice.

        1. 1

          On the other hand, all the candidates we had for the role were excellent, so maybe Elixir devs compensate their rarity with very impressive skill levels.

          Dave Thomas and Chad Fowler each wrote about this phenomenon 15 years ago in The Pragmatic Programmer and the book that later became The Passionate Programmer.

          They found that by looking for Java devs who also had experience with Ruby, that they got better applicants. Even though the position was for Java development, the candidates who had the curiosity and drive to jump into a new ecosystem were far better hires on average, even when working in the more mainstream ecosystem.

    2. 1

      Yeah that's what I wanted to hear!
      It's just painful for us developers to admit that technology is not what matters the most, especially in the beginning.

      I'm starting to really get over it now... small milestone!

      1. 2

        Honestly, I'm realizing more & more that developer != founder. I have a few full-time dev friends and they often can't wrap their heads around the idea/risk of a startup.

        Often I share a thought or milestone with a dev friend and he immediately goes into what about X, what about Y, what about Z. My standard response now is "great, but that's not MVP".

        1. 4

          I saw that in myself, going back and forth between dev and entrepreneur.

          And I blame myself for not reflecting enough for the longest time. As engineers, we're trained to see problems and solve them. Looking at a problem and figuring out side-effects and consequences gets rewarded by our teachers, our peers, our clients, our communities. Ignoring issues in the conceptual stages of development gets punished by bad grades, bad reviews, negative comments on our code reviews. We're quick to develop a product-centric tunnel vision, focussing on outcome optimization while ignoring the transformative potential of iterating consistently.

          As a founder, you learn this quickly. No product is ever finished. Trying to plan everything in advance leads to analysis paralysis. You have to ship quickly not because it's hip, but because it's the only way to see where your expectations of how things are overlap with the actual reality of your customers.

          That is scary for developers who usually get punished immediately when the overlap is not perfect when their product sees the light of day. Learning to let go of that notion, that terrible fear of disappointing myself and my customers, took me years.

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 29 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 18 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments