Start prioritzing features and organizing sprints.
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.
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:
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.
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.
According to a study on expert judgement and software estimation, 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:
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:
If you’re a start-up looking for a technical partner to be there for the ride, look no further. We specialize in helping start-ups validate, launch and scale their MVP. Contact us now to get an estimate for your app and the best technical solution for the job.