I have been responsible for building about 6 serious startup MVPs from scratch and about 5 pet projects. Some of them went great and some of them failed before launch. My mistakes made me form ridiculously strong opinions on what technologies I wanna use in my next MVP and I believe that it is the only right technology with no decent alternatives.
Before jumping to winners we have to define the criteria for winning. We are working on building a startup MVP. It means the speed of development and the community are primary KPIs. We don’t care about the performance of language. We also don’t care about how innovative it is. Also, we don’t care how scalable it is. I understand that you wanna be able to handle millions of users per second and trust me, with modern architectural stacks, any language can do that, the difference will be the price. And when you set your primary KPI as “Cost of architecture”, then let’s talk about optimizing it. Usually “Cost of architecture” and “Delivery speed” are pretty opposite KPIs. Don’t make a mistake and choose the right KPI for the MVP.
So, our primary KPI is “Delivery speed”, the criteria by which we measure language are “speed of development” and “community”.
It will depend on what kind of solution you are building but in 99% of cases you will use JS on the front end. If you wanna build a WEB app, JS is the only option. If you wanna build a mobile app, you can use from building JS based solution using React Native, Dart based solution using Flutter, or a native app using Swift and Kotlin. Building a Native app will require you to build 2 separate apps for 2 platforms which is too long for a startup. Flutter vs React Native is a kinda meme competition. I had experience using both and React Native won because he has more devs, more libraries, and an easier code base. Honestly, I never built a desktop app and I barely can imagine someone wanting to build a desktop app in 2023, but even if you do, you probably want it to work on all operating systems so you probably wanna use Electron which is again, utilizing JS.
So, whatever you do, you will use JS on the front end.
The backend is a little bit more interesting because we have 2 candidates there: JS and Python. There are no more languages that exist for building a backend for startup MVP. No Java, No Golang, and No Rust. That is why this article is called “Ridiculously Opinionated Guide…”. But, let me speak my point. Both JS and Python are considered to be the easiest languages in the world. They both are having biggest amount of developers and the biggest amount of libraries, so they are unbeatable winners based on our criteria.
Now there is a simple decision tree that you can use to choose between them, If you are building data related startup, or you are planning to train your own AI or you are building a scrapper – use Python. In all other cases use JS.
By data-related startup, I mean that it is your primary selling point. If you are building a marketplace for houses and you wanna be able to analyze house pricing it is not a data-related startup. If you are building a bot that scrapes all house marketplaces and provides you an AI chat-based access to aggregated data it is a data-related startup.
If your startup is data related, use Python, in all other cases, use JS.
Why JS in all other cases? The benefits the single language infrastructure is giving you are enormous. Any of your backend/frontend developers now become a full-stack. The full-stack developer is the only developer you have to have as a startup. You don’t need specialists, you need generalists who can handle everything. JS is the perfect language in that case.
Additionally, you can share data structures and code between your backend and front end using a shared library. This saves a lot of time, cause now once you defined DTO, front and back, both know about it. Now you also can finally have complete consistency over your data and your logic.
Now, JS is not perfect and it is kinda ridiculous when it comes to changing the code you wrote. And you wanna change code. You wanna do pivots and you wanna reuse your code during the pivot. That is why TS exists. TypeScript (TS) is the extension of JS that allows you to add strict types to the language. Imagine it to be a son of a JS and C#. With TS you have the power of C# together with the simplicity of JS. A powerful combination that makes your JS stack scalable. 100 developers can work on your code and all of them will understand the code and be able to support it due to types.
In 2023 it is the convention to use TS. If you are planning to use JS, use TS.
While using TS the framework stack is simple, no comment is needed:
WEB – React + Redux Toolkit OR Next.JS
Mobile – React Native + Redux Toolkit
Desktop – Electron
Backend – Nest.JS
You may say that Svelte or Vue.js is sweeter, but then I will say good luck finding developers to support it. There are some, but you definitely don’t wanna cut 90% of the developers’ market by choosing some weird unique framework or technology.
I love Nest.JS because of the architecture it enforces you to use. You don’t need a CS degree, solution architects, and UML diagrams to build amazing backend architecture, you just need Nest.JS. When I started my Nest.JS project, I just read the whole documentation and then I didn’t experience any code issues. Of course, we were also utilizing TS, we were using liters, we were carefully controlling dependencies, we were writing migrations and we were trying to follow the clean code.
The longer conversation is a component library you gonna use. Just use some, don’t try to build components from scratch. It is long and it doesn’t worth it, at least for the MVP. Sometimes founders are getting their designs done and require devs to implement the design. Don’t do that, if you just follow the common design components library like Material US, Ant design or at least Tailwind you gonna build MVP 3 times quicker and that is a great tradeoff assuming that “Delivery speed” is our primary KPI.
Use the components library, really doesn’t matter which one, but don’t use Bootstrap, it spells like 2001.
The database is also having some flexibility. Modern full-stack developers prefer MongoDB, I am old school guy who loves SQL and Postgres. Mongo is perfect for data analytics and scrapping where you wanna store data in a not formatted structure. However, it is really bad as a main DB. I felt huge issues configuring migrations on it and it really wasn’t created for that. So in my opinion there always had to be SQL DB in a project for highly structured and predefined entities like User, Roles, Configurations, and some more domain-specific things. But then if you have some weird data you can use Mongo for that. If you are looking for more flexibility with Postgres there is a JSON data type that will insert data complete structure in DB and automatically serialize them using ORM like TypeORM.
Even if you are building social media and thinking of how can I survive without GraphDB and a key value DB and also a time series DB for analytics, just don’t do that. In the future you will have a budget to optimize all that stuff, it is great that you have so a scalable vision in your mind, but for the MVP, just use Postgres, it can handle everything.
So don’t reinvent the wheel, don’t overcomplicate your infrastructure, and don’t go too easy with DB, just use PostgreSQL.
Startup Development Healthcheck
Based on all previously discussed we figured out that there are a lot of things that could go wrong while building or extending MVP. To help other CTOs and founders build startups without being scared of technical risks I developed a Healthcheck which is much less ridiculously opinionated and much more generalized to be able to apply for any startup project. I personally organize this health check for every startup I work with at least once in 6 months.
You are welcome to try it by this link – https://foil-millennium-d85.notion.site/Startup-MVP-development-Healthcheck-56b42f307c6d490780966dc27053e51b?pvs=4