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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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!