After crafting the look & feel of your app during Product Discovery, it’s time to put some numbers on it. The number of people, hours and, of course, the cost will largely depend on the type of app you want to build and the product requirements. There are three steps in this stage.

STEP 1. How are we going to build it?

The four pillars of a good technical solution

When suggesting a technical solution, we always rely on the insights gathered during Product Discovery, such as expected number of users or features which need to be integrated as 3rd party services.

As part of the technical solution, we carefully consider for each project:

• Architecture & design principles - MVC principles, microservices, 3rd party services (e.g. APIs, social media, video players etc.)
• Tech stack (backend and frontend) - programming languages, frameworks, data and file storage
• Database architecture - table structure, relations, indexes, database schema
• Servers & deployment - hosting solutions, server requirements and distribution

For example, when designing the technical solution for an e-commerce platform, we might focus on aspects such as extensibility (how easy is it to add new modules, themes?), integrations, loading speed, incremental feature shipping. We might then assess whether it’s best to use a microservices based architecture from the get-go or not, what’s the best hosting solution, what features should be integrated as 3rd party or modules, how the module ecosystem should work etc.

Maybe for a simple time-tracking app, it’s OK for all requests to be handled by a single backend. But what about a massive fleet management app, where you run the risk of choking your servers? And what if you also want to calculate distances or generate custom reports? This requires speed in data processing. So maybe using a technology specialized in big data, such as Python, would be a good fit. Or using a different server to do the calculations. Or precompiling the most frequently used reports in order to generate future ones a lot faster.

All of these decisions and more go into finding the most viable technical solution.

Finding the best technical solution is a (load) balancing act. And then some

To come up with the best technical solution you also need to find the perfect balance between what works now and what will work in the future. What is the expected number of users? Can the app support a growing number of concurrent users? How will it handle an exponential strain on the database?

That’s why we invest a good deal in database architecture right from the start. Database selection and design are crucial if the web app is going to scale successfully and compute fast a huge amount of data. More importantly, it has to be secure and allow for optimal server deploy and backup.

For example, MySQL offers critical elements for database applications deployed in the cloud, such as security, high availability, data integrity, monitoring and resource management. This works wonders for if your data is highly structured and you anticipate minimal changes to the database schema. However, for storing huge amounts of unstructured data in a flexible way, NoSQL or a combination of MySQL and NoSQL might be a better choice.

After settling on a database solution, we design the schema, a visual representation of how data will be stored. This includes how information is organized across databases and tables within databases, the relationship between database objects, views, stored procedures, primary keys, foreign keys etc. In short, a visual overview of your app’s data scaffolding.

Relations between tables within database schema.

Example of database schema for fleet management.

STEP 2. How long will it take?

Taking the guesswork out of time estimates

According to a study on expert judgement and software estimation[^1], group discussions appear to significantly improve estimations. This is one of the reasons we use planning poker, similar to Scrum poker, to generate more accurate time estimates.

During product discovery, we write user stories in such a way that they can be easily broken down into features (e.g. “Customer enters search criteria for product”). Features are then estimated separately by two or more developers, depending on the size of the project. This overrides the influence of other participants and the natural tendency of letting the first numbers set a precedent for following estimates. After each developer makes his or her separate estimates, we discuss them and high and low estimates are explained. If there are any huge discrepancies, the steps are repeated until an agreement is reached.

Planning poker works so well because:

• It combines expert knowledge among team members.

• It allows team members to make relative, instead of absolute estimates. This means developers compare new tasks to previously finished ones, instead of making abstract estimates. For example, is this feature closer to this really small thing? Or is it more like this normal sized item? Or is it really huge like that one piece of work we finished last month? This significantly increases accuracy, because estimates are based on hands-on experience.

• It makes project planning and feature prioritization easier. Because it focuses on the complexity of implementing features, the planning poker method makes it really easy to group these features into must-have, good-to-have and nice-to-have. This makes project planning and feature prioritization, the next stage in the development lifecycle, a lot easier.

STEP 3. How much will it cost

Converting everything into cost estimates

After figuring out the technical requirements and the time needed to implement the project, we turn everything into cost per month, per team or per entire project. There are several elements which go into cost estimates, in addition to project duration and the complexity of the technical solution:

• The seniority level of the people involved - Does your project require highly specialized people? For a complex project, one senior developer might be a better and more cost-effective option than three mid developers. Same goes for project managers, testers, designers etc.
• The urgency of the project - How fast do you intend to have it deployed?
• The maturity of the project - In which stage of its lifecycle is the project? Is this an early-stage MVP or a scale-up? Are we starting from scratch or integrating with an already existing ecosystem? Are we talking enterprise or start-up?

This is the second stage in our battle-tested process for building apps. Stay tuned for upcoming articles and share your experience in getting a development project off the ground.

[^1] U. Passing, M. Shepperd (2003) “An experiment on software project size and effort estimation”, Conference: Empirical Software Engineering.