Developers April 25, 2020

What's your tech stack for moving fast?

Preetam Nath @hipreetam93

I was wondering what everyone's tech stack looks like. I'm looking for stuff that

  • makes development faster
  • easier or less error prone

IDK you tell me! Could even be an extension for your code editor or terminal.

Our stack (my and cofounder)

  • Reactjs
  • Python Django
  • mysql
  • redis
  • python-rq for asynchronous tasks
  • regular terminal
  • Atom with no extensions

Also, a more specific question and I would love everyone's suggestions here -- What can we do w.r.t to our existing stack to make development faster/easier/less error prone?

---- edit ----

W00t! This post blew up and there's been tons of inputs by everyone. Thank you so much 🙏

Based on the recommendations, here's my takeaways and what my co-founder and I will be investigating:

Cheers everyone ✌️

  1. 14

    Hey @futurehacker93

    What I'm going to say doesn't answer your question in the way you're expecting, but I hope it is useful to you.

    From my experience writing software professionally, the tech stack has little to do with the speed/errors of the application being made. Unless you're trying to build a web application using some low-level language like C, but I don't think that idea crosses people's minds much nowadays.

    What really influences the speed of development and the errors on the software is the methodology being used to develop the software.

    Regarding reducing the number of errors in an application, the most effective strategy is collaborative construction. In other words, you need to make sure that the developers understand the business domain of the application and are close to the end-users and the business stakeholders. This gives them more sense of what they're developing, thus allows them to see more easily when they're making mistakes.

    Other effective ways to reduce errors is to have developers write tests, and program in micro increments so that they never lose control of the codebase. That's where a development methodology like TDD becomes useful.

    Regarding the speed of development, the most effective approach by far is just to ask developers to build less at a time. That means focusing on what's essential for the product and leaving out the rest. It worked well for Writely (now called google docs) that from what I heard was developed in such a way that the first prototype was out after 2 weeks.

    Other things that have an impact on the speed of development are never to let the code become a huge mess and to be sure to manage the dependencies between the modules of the application. Developing in this manner does mean that the first features tend to be a bit slower to come out since there are tooling and setup to be done, but the cost of adding new features then decreases and stays stable as time goes by. This is opposed to the classic approach where the first features are fast to come out, but adding new ones keeps increasing in cost as time goes by, until it reaches a point where it's no longer sustainable for the business.

    I hope this is helpful to you in some way :)

    1. 5

      I've preached this 100 times over, I've come to realize that people ask this question not because they care about what's best or even about what the rest of us are doing / using, but because they just want to talk about what they are using. It's like Fight Club, people are just waiting for their turn to speak.

      1. 1

        Maybe a better option than asking the question would be to look at solo devs and small teams that have been extraordinarily productive and look for commonalities.

        1. 1

          could always look at the bajillion other identical threads already on the site too... i think often times this question gets posed because the team that's curious about it is slow and/or under performing, and thus, start seeking a silver bullet to fix things.

          there's this assumption that development is extremely easy, and everything should be quick and done yesterday. the problems with slow development isn't usually the stack, but the team's ability to scope tasks down enough that they are working on quick bite-sized chunks.

          usually the management type folks asking these questions are the reason their team is slow. scope creeping and all of the usual pigeoning that comes along with it.

          1. 1

            Nobody uses the search feature on forums.

            Welcome to SG-1 S04E06, AKA "Groundhog Day"!

            1. 2

              LOL fair

              In before the no-code "let me IH search that for you" SaaS app drops.

    2. 3

      I second this post. With regards to the tech stack the best thing you can do is pick what you're the most familiar with. You'll always be able to rebuild it later if you have scaling issues (if you do that's a GREAT problem to have).

      I just want to add a very practical tip to accelerate dev: do your best to deploy to production everyday. That means automating deployments and tests, shipping smaller bits of code, and having proper monitoring on your production. Best is to read about continuous delivery, most of the literature is for big cos, but it's really applicable to startups.

      I also have 5 rules for simplifying dev:

      1. Choose the familiar rather than the exciting — every innovation comes at a cost
      2. Don't trust yourself — Document things, write comments, add tests.
      3. Don't be clever — clever code doesn't save CPU, but it'll consume your brain cells
      4. Split frontend from backend — a simple way to segment business logic from presentation
      5. The default answer to creating a new service should be "No" — new repos and services should be painkillers, not vitamins.

      If you want to read more I have a post at

    3. 2

      Hmm... I think it really depends.
      Your advice is definitely the only viable option for enterprise development and the best strategy to keep the error rate as low as possible.

      However, I'd like to add that whether this is actually the best strategy depends on the specific case and additional factors like:

      1. How large is the code base and how large is it expected to grow.
      2. How early is the stage of the product.
      3. How many developers are working on the code base? One or two developers with full knowledge of code base's full history are very different from 100 developers.
      4. How critical is a specific part of the system? This greatly influences the necessity and strength of tests.

      I've seen two different kinds of extremes throughout my career.
      On the one hand, there were people who "hacked away" at large long lived code bases, making them even more unmaintainable. But on the other hand I also observed best-practice bikeshedding in cases where it is definitely not applicable, like for a one-time-script.

      It feels weird to say this, but in some cases development with technical debt might actually be the preferred option.

      1. 1

        I agree with you in that an analysis of how an application should be built based on its specific business context, is more important than any "best-practice" that might be out there.

        I do tend to stay on the safe side of the fence. I find out that it's hard to predict how large a codebase is expected to grow, or how many developers a project will need as it grows. So I tend to just write code as best as I can for what the project is supposed to do right now. From what I've seen, it is when someone tries to predict the future that "best practices" start to become a pain.

        Regarding technical debt, if it comes down between technical debt or keeping the company running, there will be some nasty code. The only concern with that code besides it working will be, "How can this be organized so that we can delete it later and make it new?".

    4. 1

      you need to make sure that the developers understand the business domain of the application and are close to the end-users and the business stakeholders.


      errors is to have developers write tests, and program in micro increments so that they never lose control of the codebase. That's where a development methodology like TDD becomes useful.

      Partially disagree. I think it depends on your definition of "moving fast". If you mean "get in front of users and iterate as fast as possible", tests will (IMHO) only slow you down. This is particularly true if you only have one or two developers.

      If you know exactly what you want to build, then I'd probably adopt TDD. Particularly for larger teams.

      the most effective approach by far is just to ask developers to build less at a time.


      As a developer, though, I'd also point to:

      1. a stack that supports hot reload - the difference in edit-compile loops per day can sometimes be an order of magnitude.
      2. good hardware. Same reason.
      1. 1

        Hey Nick!

        I can see that we agree on almost everything :)

        Regarding tests slowing you down, in my opinion, it depends on the expertise people have writing tests. A lot of people know how to code, but not many know how to write tests. So when they start writing tests, things tend to go pretty slow.

        We can argue that there's no value in automatically testing something that we'll likely throw away eventually. And depending on the situation, I might agree. However, I do like to be sure that the demo I'm showing to the future client won't fail me. So having a suite of automated tests, even if it's not a huge one, keeps me more at ease.

        Regarding TDD, I don't believe it to be the end all be all that a lot of people preach, and you can be top developers without it. But I do use it and have been using it for years now. One of the reasons I like it is because it tells me what I don't know about what I want to implement. But that's only my experience :)

    5. 1

      Thank you for taking the time to write this. My co-founder and I will think deeply on what you said :)

      I should have added additional context in my post - we are a team of 2 developers (I'm a beginner) trying to be more productive with our finite resources

      1. 1

        If you want to go deeper into the subject, I recommend you check this book You'll get some interesting insights from it.

        I hope your startup takes off :) Good luck!

  2. 8

    The best tech stack for moving fast is the one you know 😄

  3. 6

    I can code in almost 20 languages, many frameworks, most major platforms, and still, to move fast, I code in Ruby on Rails and deploy on Heroku.

  4. 5

    I personally like to use VSCode the best and you should give it a try.

    1. 1

      intellij IDE is much better.

      1. 1

        WebStorm for web dev; Pycharm for python. I love all things jetbrains!

    2. 1

      Shall give it a try :)

      Why do you suggest VSCode over Atom?

      1. 2

        I prefer vscode because of the communities live for it. It also has tons of extensions and a nice live server.

        1. 1

          Awesome. Could you share some of your favourite extensions?

          1. 1

            Live Sass compiler, react snippets, live server are among my favorites

            1. 2

              Thank you so much ✌️

      2. 1

        VSCode has a huge community behind it, the update rate of the editor is insane, every month there's a huge list of improvements and new features, plus it supports by default a lot of cool stuff and you can also find a plugin for whatever you need. I think it's without a doubt the best editor you can use today if you do front-end development (TypeScript).

      3. 1

        This comment was deleted 7 months ago.

  5. 4

    I would echo what @jnforja posted in this thread. The actual semantics of the tech stack has very little to do with the success of the project.

    The important thing is to build using tools that you are already familiar with. Don't just jump on the latest framework that is the darling of all the tech forums at the moment. You don't want to be learning new ways of doing things while you are trying to solve a business or a real world problem.

    Our own SaaS is seeing some success lately, and a lot of it is built on tech that is YEARS out of date, but it is tech that I know really well so I can execute quickly without have to refer to Google or StackOverflow to remember syntax or find out how to do something programmatically.

    Also, avoid tech debt early on. Always use best practice methods to ensure clean and readable code. That '20 line quick fix that I will redo in a few days' almost always ends up being critical code that sticks in the system years later and hampers your growth and that no one wants to touch for fear of breaking things.

  6. 3

    The best stack is the one in which you are most comfortable and productive with. No matter current fads.

  7. 3


  8. 2

    For me, it's very simple. If I need real webapp capabilites, I'll go for Rails + SQLite at first (should this grow, I'd go the Postgresql route on the DB side). No frontend framework, only Rails.

    If I only need a few static pages, then Middleman is my go-to tool to generate static pages.

  9. 2

    Laravel & VueJS
    GitLab & GitHub

  10. 2

    W00t! This post blew up and there's been tons of inputs by everyone. Thank you so much 🙏

    Based on the recommendations, here's my takeaways and what my co-founder and I will be investigating:

    Cheers everyone ✌️

  11. 2

    Ruby on Rails + Heroku

  12. 2

    Depends for what, but I think the fastest for small projects is still plain JS/HTML/CSS frontend and PHP/MySQL backend, which I still use sucessfully for some of my projects.

  13. 2

    ReatJS + AWS Amplify + CloudFront

  14. 2
    • Digital Ocean
    • NGINX
    • Django
    • Postgres
    • Vue
    • Nuxt

    I started this repo to get a web app with all basic features started with just git clone, but it's still work in progress:

  15. 2
    • Laravel
    • Heroku
    • Stripe
    • Twilio
    • Mailchimp
  16. 1

    firebase with react.

  17. 1

    To be fast, I took some radical, and mostly untrendy decisions:

    • use a real programming language (compiled, strongly typed...): I chose java, but I think there are some equivalent choices.

    • use when I can automatic code generation. This plus the debugger means most errors are visible immediately as it does not compile.

    • Build a library of non-trival stuff that is always repeated across projects

    • do not use a web client (for my area of enterprise software). You could spend all of your energy just running after the latest framework, whereas basic ergonomics concepts do not move a lot, like a few improvements per decade.

    All this resulted in the lowcode framework Open Lowcode ( ). Feel free to have a look.

    Being efficient in development is not the only factor of course, ideally, you want to do development of a business idea that is already debugged. Having the idea you want to code for implemented as a prototype in a spreadsheet first is a good idea.

  18. 1

    All JS everything on Cloudflare workers! Fast, cheap, and so easy to dev on.

  19. 1

    My current tech for fast development is:

    Node.js + Express

    currently working on and

  20. 1

    About tech:

    Moreover than everything wisely said here I would add that I personally bet on Web Components.

    There are easy to develop, specially with, and less error prone as they encapsulate their feature.

    They are also future proof. Regardless of which frameworks or none I'm going to use in the future, I will be still able to reuse them without having to migrate or rewrite them.

    About tools:

    I use Webstorm because the Git integration is well made and it's refactoring capabilities are a great assets to speed up development.

    About cloud:

    Firebase works well. Auth is free. FCM for push notifications is so far the easiest solution I found. Firestore and Function work well together.

  21. 1

    Looks like I'm the only .NET developer here <shrugs/>

    I find Blazor serverside and some basic GitHub Actions and Docker compose file to be an extremely potent combination to get something buildable and deployable to a sufficient level and at a reasonable velocity.

    I've looked at React, Vue, Angular etc. many times and they seem to end in a soup of dependencies and disappointment, although they seem to work for almost everyone else here!

  22. 1

    This prolly works for me because I have good amount of experience with my tools.

    Typescript if I can. Serverless if I can.

    Preact (tsx) + jss (css in ts) + webpack for frontend
    Ts-node (typescript + nodejs) in backend.
    A whole bunch of shared code for api types and business logic in a common directory.

    For server I recently moved to GCP

    GCS for static assets. Costs 2.6c per gigabyte per month.

    Google cloud run for serving the website. It basically spins up the server docker image when there is traffic and spins it down when no traffic for a minute. It can auto scale based on concurrent requests up to 10k instances. I’ve set mine to max 100.

    Google cloud build - for automatically building docker image and pushing to cloud run when I merge a commit to master. Deploy to prod is done in a minute.

    Google cloud firestore as a db - only get charged for read/writes and storage. Has built in auth and support for change listeners.

    I use cloudflare for static asset cdn since it’s fast and costs me no money. Google has cdn but they don’t autoprovision https ssl certs like cloudflare.

    My hosting cost last month was 50c. I can prolly scale to millions of visits per hour if there is a burst and scale to 0 when no traffic. Cloud run is honestly a god send.

    I’m sure you can do the same things with AWS and Azure but I’ve used GCP for a few years and they do a decent job at the basics.

  23. 1

    Angular 2+ (Please don't kill me)
    ASP.NET Core or Express.js depending on the project

  24. 1

    For anything new:

    • express.js / on the backend
    • react.js for front end apps
    • typescript for both
    • jekyll for marketing sites
    • mongodb for persistent storage
    • redis for caching of computational heavy stuff (not for caching to reduce database hits)
    • docker for local development, but not in production
    • gitlab runners for ci/cd
    • vim. always vim.

    I still do a ton with less modern stacks, like PHP and server-side rendered pages. The cost in time to migrate just isn't justifiable IMHO, plus having multiple stacks helps keep me nimble in terms of being productive on multiple stacks at any given moment.

  25. 1

    My current tech for fast development is:

    • React
    • Node.js + Express
    • MongoDB or AWS DocumentDB

    By keeping everything in JavaScript, I only need to think about one language. Plus since I’m just sending JSON down from the database -> server -> browser, I don’t need to do any time-wasting serialisation or formatting of the data.

    1. 2

      What do you use for authentication and where do you host the front- and backend?

      1. 2

        I usually just write my own authentication with bcrypt but I have used Auth0 in the past but actually just found it more time-consuming and restrictive.

        For hosting, I'm loving Netlify for the front-end and AWS EC2 instances or Lambdas (not Express) for the API/back-end.

  26. 1

    For web it is

    • PHP with custom made Framework using Phalcon that scales extremely well (I might open source it one day)

    • MySQL

    • Redis

    • some React components for UI interactions but not a single page frontend

    • switching to a full ReactJS frontend only at a later stage because I don’t want to mess around with server side rendering

    Everything in a docker environment to spin up a production instance pretty quick.

    For iOS apps it is

    • Swift with Firebase Backend

    Figma for designing interfaces
    PhpStorm or XCode IDE

  27. 1
    • React, Gatsby, javascript in general
    • Netlify
    • Serverless as far as you can wing it. You can do so much on the client now, plus it is free for you and scaleable
    • Hexo + NetlifyCMS for writing content
    • IndexedDB
    • Firebase when you need a fast backend or cloud functions or auth provider
    • Kotlin/Android Studio for Android clients (not particularly fast, industry standard)
    • Heroku or Google cloud for running a server, if you must
    • Stripe for payments on website
    • Gumroad, ebay, etc. when you just want to start selling products, today, now!
    • Use nocode when possible, examples:
      • I'm a dev but I use squarespace for making websites for some clients because it is fast and easy to hand over if need be.
      • Reason why I use netlifyCMS instead of trying to reinvent that wheel every time
    • also I use sourcetree because I don't like to fight with git in a terminal YMMV

    .. uu and almost forgot: App Mockup Builder for when you are ready to publish apps

  28. 1

    my tech stack:
    php symfony framework on backend
    react.js front
    apcu for cache(redis alternative)

  29. 1

    I'm new to the development game but I'm currently using React, Go, Docker, Digital Ocean, and MySQL(MariaDB).

  30. 1

    My current favorite is:
    keystone.js + gatsby.js (with material ui components)

    It feels fast to me because keystone is effectively very similar to django.
    And easier/less error prone than other approaches with decoupled front- and backends, because everything is graphql based and the tooling around apollo server and apollo client is very strong.

  31. 1

    Node/React/MySQL/Stripe boilerplate

    1. 1

      What do you use for auth and where do you host these?

      1. 1

        I use Gravity ( which has auth built in and host on Heroku (

  32. 1
    • Next.js
    • Firebase Auth
    • Cloud Firestore
    • Bulma
    • Stripe
    • Vercel (formerly Zeit)
    • All of the above + UI with Divjoy
  33. 1

    Spring Boot, Java, ReactJs and Heroku. Since I have used Spring Boot extensively, it is easy for me to build a database supported web-app within a month or two. Of course, it also depends on what kind of application you are building.

  34. 1

    — React/NextJS
    — Hasura (GraphQL engine. Super easy to add tables and have all your standard crud operations. It can also handle permissions etc.)
    — Zeit (now Vercel)
    — TypeScript

  35. 1


    For a half static/half dynamic website with authentication. No backend required.

  36. 1
    • GOlang
    • React
    • AWS
    • Docker
    • SQLite3 or MongoDB - depends on what I am building.
  37. 1

    I'll put a plug in here for

    We used this to build Summit (, and are very happy with the results.

    1. 1

      Love the value prop being pitched by darklang. The documentation does caution against using it in production apps as of now though

  38. 2

    This comment was deleted 8 months ago.

  39. 1

    This comment was deleted 9 months ago.

Recommended Posts