In this write-up, we will have an in-depth discussion on how many developers we really need for our startup or to build an app. Is it just one, a couple or more than a couple?

Finding out the optimum number of developers to work on your app depends on several factors such as the complexity of your product, the scale you would be operating at, competition in the market in your domain, the application infrastructure you pick to deploy your app, the time frame you have in mind to bring your product to the market and so on.

There are quite many factors that come into play, the ones listed above are the key ones.

Let’s discuss this, in detail.

Are you building an MVP (Minimum Viable Product)?

An MVP is the most basic tangible form of your idea with the bare minimum, necessary features of your app. In an MVP, we typically throw out all the good to have and just keep must-have features.

This helps with the initial traction and gives us an insight into the reaction of the early adopters of our product. Also, we can showcase it to potential investors (if you are looking for external investment). MVP also helps the teams start small, move quick and iterate regularly adding new features as the business moves forward.

Since an MVP is not the final product. It should ideally take one to two developers to build it up. You would not typically need a big team to develop an MVP. Also, you should not hire a big team in advance since in the initial stages we need external feedback to really carve out the path we need to take with our product.

Once things are concrete based on the future product roadmap, we can hire specialists to add new features. Often businesses cut out most features from the MVP to launch the first version of their product after external feedback. Why invest resources upfront building stuff you might cut loose?

Are you implementing a full-fledged production system? What is the scale and complexity of your application?

If you are past the MVP stage and looking forward to the alpha or beta version of your app. The number of developers required depends on the scale and complexity of your project (small, mid-sized or massive enterprise project).

Let’s take an enterprise project like an e-commerce app for discussion. We have to first figure out the possible domains. For instance, an e-commerce app will have domains like inventory management, order booking, order routing, order delivery, user subscriptions, payments and so on.

These domains will have respective systems on the backend comprising one or more microservices powering them. Every microservice will have specialists like frontend devs, backend devs, full-stack devs, database specialists and so on. At the bare minimum, we can assign a couple of devs to build a service. And this is a very high-level guestimation. Unless we know the functional and non-functional requirements of the system, we cannot come up with a specific number. There are quite a number of variables that come into play making it hard to come up with a specific number.

Developer skill set

If your product has a frontend that would run on the browser, your team should have a frontend developer and a backend developer for the backend. A full-stack developer would be good to have since they would have the knowledge of both frontend and backend development saving you some money.

Additionally, the key is to have someone in your team who is experienced in system design and application architecture. You need someone who would oversee the product design and architecture besides picking the right technology stack for your app.

Once the product’s design and architecture are finalized and your team gets down to coding. You cannot afford to look back. There is no scope to backtrack and change the tech stack or the architecture at a later point unless you wish to push your launch date by months if not a year.

Startups don’t have enough time and resources to pull that off. If the core design is flawed, it might become hard for you to integrate new features with the existing code in the future. You may even have to re-write a lot of stuff from the bare bones. Therefore, it is super important that the person designing and picking the technology stack is seasoned.

Developer velocity

The present software development industry runs on the Agile software development methodology. That’s the defacto methodology we use for building products. Following Agile, we ideally plan to work for a Sprint which has a duration of a fortnight. And at the end of the Sprint, we determine how much did we achieve? This is called developer’s velocity.

Based on the work and the deadline. We can compute if we need more devs on our team, after a few sprints.

Application deployment infrastructure

This is key in deciding the number of resources we need on board. The more managed cloud services we use the less the number of resources we need to build our product. This is the primary reason every startup is deployed on the cloud with managed service offerings.

Deploying apps on the cloud saves us a significant amount of time enabling our devs to stay focused on implementing the business logic instead of worrying about managing the infrastructure, security and a lot of other stuff (the primary reason behind the popularity of serverless computing).

If you intend to deploy your app on the cloud, not on-prem, this cuts down the need for additional developers and infrastructure engineers to a big extent. Cloud takes care of all things with respect to infrastructure management such as server provisioning, cluster management, global deployments, infrastructure security, backup and such.

If you wish to understand application architecture, infrastructure, fitting technology stacks, cloud and distributed design of large-scale services from the bare bones, check out the Zero to Software Architect learning track I’ve written. It is meant for software developers, aspiring architects, IT consultants and anyone who wants to have a firm grasp of system architecture.

If you are someone who is in a management role, the knowledge gained from this course will help you have an understanding of jargon like scalability, high availability, performance bottlenecks, etc. resulting in effective communication with the developers on board which in turn will help you:

  • Plan your project better
  • Provide well-estimated timelines to the stakeholders
  • Relate business domain rules with technology implementation
  • Communicate the technical issues to the business people better
  • Improve project velocity

Competition in the market?

Having competition in the market means no slacking off. You have to launch features fast, continually, this means having an optimum number of developers on board. We cannot afford to lag behind when our competitor is introducing new features to their product frequently.

Why is it advisable to have atleast a couple of developers on your team?

Having more than one developer in the team helps quite a lot during the code reviews. You can ask the devs to verify each other‘s code and point it out in case something is amiss. Also, it’s always helpful to have someone on the team with which a dev can bounce their ideas off, have technical discussions and such. This keeps the ball rolling.

There are several ways to hire developers. You can get in touch with them on LinkedIn. Hire remote programmers on a contract basis. Hire college grads if your team thinks they can quickly train and get the freshers to do the required work.

You can organize a hackathon, ask the community to write utilities for your product and you can set monetary prizes for that.

If you found the content helpful, check out the Zero to Software Architect learning track, a series of three courses I have written intending to educate you, step by step, on the domain of software architecture and distributed system design. The learning track takes you right from having no knowledge in it to making you a pro in designing large-scale distributed systems like YouTube, Netflix, Hotstar, and more.

Well, this was pretty much it. A bit about me.


I am Shivang. I have over ten years of experience in designing and developing large-scale distributed systems. Worked for some of the industry giants in different domains. You can read more about me here. If you found the content helpful, do share it with your network for better reach.