How to choose tech stack for your new startup?
Tags: startup, programming, softwaredevelopment
Published: 2023-10-17 12:12:45

## Why do you have a .NET system?

In Dodo, often when I talked about the tech, the question was asked - why is everything written on .NET? The answer was as if every time they were waiting for a story about comparison, objective reasons, performance, people, etc. And the answer was extremely simple and prosaic. The first 2 developers who believed in the project, knew .NET. That's the whole reason.

Now for me the question "What kind of stack to take in a startup" is relevant. What will be the scale? What kind of experience (domain and technical) would I be interested in bringing developers to the company? What scale of team would I even need to assemble potentially? And in what regions? 

These are all relevant questions. However, they are relevant for the scaling phase. They lose weight when they start thinking about what they have "here and now". Launching a startup is a situation when you need to launch something as quickly as possible, test the product's fit as quickly as possible, to make 1-2-3 pivots to find something to scale. And so we look at the here and now. 

You make a financial product, 99.99% of fintech startups are launched on Java/Kotlin (well, I think so, maybe the statistics are a bit different, but the vast majority are on them). But if a technical co-founder does not work with Java, but knows .NET, you can build fintech on .NET, at least the first versions, some services, but scaling and launching new products inside the company on Kotlin.

You make a corporate product for B2B, and it is clear how to make it on .NET, easy integrations, reliability, and security, but the technical co-founder knows Python. So launch the first version in Python and develop it. And then decide whether it makes sense to change the stack at all.

## Cloud

But in the context of Google Cloud / AWS / Azure, everything is not quite the same. Everything depends not on your skills in working with a particular cloud, but on prices, the features of your product (and, accordingly, the resources you need), as well as the geography of data centers. While you are at an early stage and the product is small, changing the cloud solution may be easy, but at the stage of primary growth you will not think about it and will be hooked on one of the providers for a long time.

They all have their own startup programs for different amounts and when you get your first investment and connect to one of the programs - that's when you make your choice. Price, geography, and focus of your product are key criteria. For example, you are doing a startup and you will work with language models, [compare](https://www.predera.com/blog/generative-ai-offerings-and-llms-a-comparison-of-google-vs-azure-vs-amazon) the capabilities of providers in the LLM area and choose. Or you want to do a service for the Middle East, it's important to store data in the region, look at the geography. 

[AWS geography](https://aws.amazon.com/about-aws/global-infrastructure/)

[Azure Geography](https://datacenters.microsoft.com/globe/explore)

[GCP Geography](https://cloud.google.com/about/locations#multi-region)

## Free Tier

In addition to choosing a stack and a cloud, there's another very interesting challenge. You are a startup, you don't have any money, and even if you do, you don't have much and it would be good to save money. Almost all services provide Free Tier, you can actually build a full-fledged product under Free Tier. The only thing is that it is easy to get confused in them and they are very different. Big kudos to the guys who prepared [a great guide](https://free-for.dev/#/) with information about Free Tier of different services, categorized. 

Database on Aiven, message queue on cloudAMQP, Sentry for error logging, Grafana Cloud for monitoring, Mixpanel for analytics, and GCP for hosting with the first $2,000 credits before we even raise the first startup investment. Running a demo/mvp of the product, and spending $0 on services is more than realistic.