Software Development Duration: How Long Does It Take to Build a Product?

The IT industry is growing and changing very rapidly. But the market is packed with similar products. If a product is regular, users turn away from it and look for more progressive alternatives. That’s why it’s a matter of survival for product owners to find balance between launching a new product as fast as possible and not miss the relevance of the new idea during the all stages of its implementation. So here I’m going to talk about timing.

How to estimate the right software development timing? As a Delivery Manager at Mad Devs, I often work on eliciting project requirements and preparing estimates before a project starts. This article is a reflection on my humble experience that aims to provide straightforward answers. The answers can help customers who look for a reliable contractor to understand how development timing is shaped.

So timing is an incredibly important indicator because it affects the final cost of development, feasibility of research results and the actuality of the future product in the market. To calculate the time for development, there is the Time-to-market metric, which shows the time from concept to the final launch. And I will tell which key elements it implies for the development of a whole new product.

Clients’ concerns

Here are common questions that our clients often ask:

• The analog project is SO simple. Is it so difficult just to copy it?
• How come MVP development takes ~6+ months?
• We use multiple integrations in the project. Doesn’t it save us time?
• I’ve got three completely different estimates from different vendors. How should I distinguish between them?
• What happens after the project is launched? How do I make changes after launching if necessary?

Your competitor’s product might be very simple in use, but you can never assess how much has been done to develop it. Consider these questions: Did they develop it from scratch or based on a ready-made solution? How big was the team? What was the functionality of the first release? How is the development process organized?

If we don’t know the answers, we can’t tell how big the scope was or how much time the development of a product took. But in answering these questions, we can identify the main factors that shape development timing.

Key factors of a software project’s timing

1. Product development purpose
2. The clarity in product requirements and vision
3. Team composition
4. Organizational process

Importantly, these factors will affect not only the preliminary estimate but the final timeline as well. So I’ll cover each one in detail.

Development purpose

There is a big difference between developing a product to validate an idea and using a product as a stepping stone for a full-fledged business.

Idea validation

If your purpose for building a product is to validate an idea, the development team works towards launching the product as soon as possible. In other words, the team focuses on critical features only. It means that certain development processes are eliminated from the project: for example, documentation, automated tests, and code review. The emphasis is on delivery and getting feedback from real users.

It’s important to understand that, if a product built like this succeeds, you’ll most likely need to rewrite it from scratch. Poorly written systems with weak foundations are hard to support in the long term. To save even more time and money on idea validation, try to look for existing systems that may fit the requirements fully or partially.

For example, pay attention to low code/no-code solutions in kind of website builders and relatively recent application builders for mobile devices. They allow you to quickly release a prototype of a working app, which will show the degree of users’ interest and help to get feedback from them. It will allow taking interviews or getting a CJM (Customer Journey Map) that will show should you realize this idea? How to do it in the best way and which specialists you need? And if the idea is worth the investment of effort, time and money, then you can safely hire a team of professionals.

Here in Mad Devs, we offer both of these things. We can analyze an idea in a variety of scenarios, assemble appropriate prototypes with minimal use of resources, and provide a variety of metrics indicating the real potential of the future product. Also, we provide end-to-end development and support of the product. As well as each of its stages separately.

A full-fledged business idea

If you are determined to create a product that will be competitive in the market, the development team will focus on building a stable and scalable system that will:

• Handle large numbers of users in future
• Have an enterprise-level of stability and security to initially avoid the possibility of critical bugs leading to bad reputation among users and large financial losses
• Be easily understandable by new team members, so that the “bus factor” is ruled out and the risks of specialist replacement are minimized
• Be easily supported, so that the development of new features doesn’t require changing the entire architecture.
• Be well documented that anyone who needs to study the project can get all the data they need from one source in a clear way and help new specialists get up quickly and easily.

Why building a competitive product takes a long time

The development process involves more than actual software engineering. Apart from coding, development is about:

• Writing technical and business documentation and keeping it up-to-date
• Covering modules with automated tests to ensure that every deployment to production is safe
• Setting up CI/CD to save time on routine processes
• Management of a team and organization of communication between all members in product development, to distribute tasks so that they are all performed consistently and there is no downtime
• Possibly other processes depending on the specific characteristics of a project

These activities usually take 30-40% of development time. They fully pay off in 1.5-2 years. If a project lasts for more than 6 months, they bring value by saving time on regression testing and preventing several cycles of internal testing & feedback before releases. Also, properly established processes, attention to all important aspects, and high development culture, in general, attract developers at a much higher level, who don’t just want to make good money, but feel like they’re in the right place.

The clarity in product requirements details

At the beginning of a project, requirements are not yet clear (presented as a vague list of features or as an example to be copied) and design is absent. With unclear requirements, it is almost impossible to predict exactly how much time development will take.

Let’s say we need to develop the simplest signup feature. Here are examples of questions we’ll need to address to estimate the scope of work:

1. What exact information does the user need to specify when signing up?
2. Should all the data be on one screen or split into several ones?
3. Do we need 2FA with signup confirmation by email or SMS code?
4. Are we going to enable signup with social media like Google+ or Facebook?
5. Should the user be automatically logged into the system after signup and will it be optional?
6. Does the signup feature include inviting contacts to the app?
7. All these factors can significantly affect the development time. That’s why quotes usually cover not only the functionality you requested but also risks and time needed to change the scope.

When a team lacks clear requirements or time for deep research, the time estimate is very rough. To better understand the quote, ask your potential vendor to break down the time estimate into features to showcase the details. It will not only help you to define the accuracy level but also give you more information for smarter decision-making. It also affects the subsequent workflow. If features were not originally intended to be added, adding them quickly can lead to bugs, making the end goal harder to achieve, worsening the application's structure, causing more communication between developers, and discussing problems.

Team composition

The time estimate can vary significantly depending on team composition, which basically means:

• How many and what kind of specialists are included in the team?
• What are the experience level and background? Everything is simple here. Depending on the stage of a project, adding more people to the team can speed up the development. Yet the marginal value is diminishing, so doubling the number of developers won’t always increase the development speed two times.

An important thing here is how the tasks in the project are connected to each other. Let’s say you need to develop a web application and mobile ones. You can hire different people and extend your team. Yet, if you need to develop a single module for an already existing system, team extension probably won’t help. Also, keep in mind that the bigger the team, the harder it is to manage.

Additionally, the experience level and industry knowledge of team members are crucial. If a specialist has a specific background fitting the project, it will be easier for them to grasp the context of the development process, suggest optimal solutions, and highlight potential risks.

Two junior or even middle developers in most cases won’t replace a senior one. Especially in high-load projects that require thorough preparation and architecture design & planning. Without the contribution of senior developers, it may turn out your product is not sustainable at all.

Conclusion

The unfortunate thing is that you’ll know the accurate estimate only once the project is complete. There will always be some risks and uncovered black boxes along the road. The good news is that you have the tools to manage this process.

The key to project success is knowing the problem and striving to solve it rather than developing something that already exists just because it’s already worked for another company. This approach will allow you to promptly maneuver your dedicated team and achieve the needed results.

Previously published at maddevs.io/blog.