SW engineering, engineering management and the business of software

subscribe for more
stuff like this:

Reasonable Tech Stacks for Early Stage Startups in 2021

If I don’t mention your favorite tech stack, please let me know via twitter. I know about a lot of them, but I don’t know every single one.

As for defining early stage startup, I’m talking about very early stage. As in the just one or two technical co-founders or single digit number of engineers. All the tech stacks mentioned in this post will scale from early stage up thru 30-50 or so engineers. Many will scale much further beyond that, but every startup’s technical needs/situation is different.

It probably doesn’t matter and you should use what you know.

There are about a thousand things to learn and do while launching a startup. The default advice of use whatever tech stack you already know will always be good advice, because since you already have to learn about fundraising environment, the market, the industry, your customers, the pain points, marketing strategies, competition, etc.

The most important thing is that you are able to move fast. By move fast, I mean experiment, iterate, test out ideas, solve pain points that your customers have and provide value to a viable market.

Don’t worry to much about scale until you’ve

  1. hit product market fit
  2. figured out a working, scalable go-to-market strategy

Both of those things are hard and building or scaling too much before hitting one or both of them will set you back.

Always feel free to ignore the rest of the advice here or ask me about your tech stack on twitter

Lastly, this covers fairly normal web and mobile apps. Transactional business logic stuff. If you have some exotic platform or needs (crypto? 3D? ML?) there’s a good chance that none of this applies to your startup.

Web Apps

For web apps, you have many reasonable choices. Roughly splitting them up, you have FE-centric, BE-centric or traditional FE/BE architectures:


This is my current favorite for early stage startups. I think it allows tremendous velocity in the early days of a startup and scales quite well as the product and market matures.

All of these technologies use websockets or similar to shuffle small chunks of json or html between the backend and the web browser instead of doing heavy lifting via client-side frameworks such as react or vue.

In general, they load faster, feel just as responsive and in some cases, change how you staff your eng team. Specifically, they reduce the need to hire or have FE ecosystem knowledge. This can make a big difference in the early days when technical bandwidth is sparse and expensive.

  • Elixir, Phoenix, LiveView
    • Elixir is quirky, but my current favorite. This is also known as the PETAL stack.
  • Laravel, LiveView
    • PHP is a reasonable language to make a web app. It’s obviously not perfect, but it’s nowhere near as bad as some of haters suggest.
  • Ruby, Rails, Hotwire

There are others, but the three above stand out to me. Even dotNet has SignalR which is another similar in spirit tech. Feel free to reach out via twitter if you know of more.


  • React with no backend
    • React front end with a firebase or similar backend service
  • React with light backend
    • Use something like express.js or a bunch of serverless functions with a managed database (RDS, etc.) or firebase.

If you really don’t like react, vue.js is a reasonable alternative for any of the above.

This architecture has the advantage of minimizing the BE development bandwidth. If you think you may need a mobile app, ReactNative is an ok choice for apps that aren’t too complicated.

Traditional FE/BE

This section will be boring. Use what you know. Golang, JVM, dotNet, python, RoR, Phoenix, Laravel, whatever.

You can do traditional server side templates or react/vue on the FE.

The minor downside here is that you have to simultaneously develop two distinct codebases and the API layer between them. This will slow product velocity a bit, but is usually offset by the whole “use what you already know” aspect.

My only recommendation is to avoid something super exotic like Haskell or even Rust. You want something with a healthy web app ecosystem. A good barometer is the existence of a robust, trusted Auth library for your webstack. It should handle user auth, proper salting, email confirmations and ideally SSO with google, github, and other major oauth providers.

I don’t think you necessarily need all of that in your web app, but it does signal a wide variety of web apps have made use of that particular auth library. Most web apps have auth of some kind and the existence of a healthy auth library or framework is a reasonable proxy for the overall health of a web framework.

Mobile Apps

If you need a mobile app, your choices narrow a bit. I’d argue that many startups think they need both web and mobile apps probably can get away with just a web app in the early days.

Even the BE-centric apps works just fine if you invest time in a responsive design.


Instagram and Clubhouse notably did not ship with Android apps and that didn’t seem to hurt them. Are they outliers? yes. But the iOS market is more that large enough to support the vast majority of early stage startups. You are looking to validate your ideas.

If you do need a mobile app, My personal choice for an early stage startup would be to make a native iOS apps in Swift due to the very high product velocity.

If you don’t have access to a Mac or XCode, doing Android-only in Kotlin or Java would be an alternative here.


For simple apps, prototyping or early customer development, ReactNative is fine.

My personal experience managing mobile teams however, it that as complexity grows, devlopment velocity slows. You are building through five or more layers: iOS -> Cocoa -> JS interpreter -> React -> ReactNative -> your code.

Sometimes things break and you have no idea where this issue is in any of those layers.

iOS and Android

Again, you probably don’t need both in the early early days, but if you’ve raised some funding, I find native mobile apps to have the highest product velocity.

Desktop Apps

Similar to mobile, you probably don’t need a desktop app. Your choices basically come down to native or electron-style shim around a web app.

I always prefer native apps as a user. And if your users are on the a desktop they almost always already have a browser.

Your choice tech stack probably doesn’t matter

At the end of the day, your tech stack probably matters less than your hustle, knowledge of the market, deriving customer insights and ability to market to an audience and sell value to your customers.

Spending a month to learn a new tech stack because I or someone on the internet liked it or was successful using it is not a great use of your time. Instead, use that time test your ideas against a market, understand how your distribute a product, or do things that don’t scale.

Best of luck and I hope your startup does really well!

in lieu of comments, you should follow me on twitter at twitter/amattn and on twitch.tv at twitch.tv/amattn. I'm happy to chat about content here anytime.

the fine print:
aboutarchivemastodontwittertwitchconsulting or speaking inquiries
© matt nunogawa 2010 - 2023 / all rights reserved