<aside> <img src="https://prod-files-secure.s3.us-west-2.amazonaws.com/c1ddc281-3cf1-4ebe-b1fc-d1b4341cbb02/0ecd3f04-947c-4be8-88f5-57cb1779ce3a/Group_480959157_(1).png" alt="https://prod-files-secure.s3.us-west-2.amazonaws.com/c1ddc281-3cf1-4ebe-b1fc-d1b4341cbb02/0ecd3f04-947c-4be8-88f5-57cb1779ce3a/Group_480959157_(1).png" width="40px" /> This document provides valuable insights into Fulcrum’s development processes and workflow—a practical guide designed to benefit our clients and partners.

</aside>

<aside> 💡 Here you can find information about our processes at Fulcrum

1️⃣ General flow of work 2️⃣ Project scoping & Estimation 3️⃣ Project status tracking 4️⃣ Your involvement 5️⃣ What might go wrong? 6️⃣ Tools we use 7️⃣ HR & Account management 8️⃣ FAQ

</aside>

<aside> 💡 Here you can find information about general best practices

1️⃣ Agile (Scrum & Kanban) 2️⃣ Best practices for MVP development 3️⃣ Glossary of tech terms

</aside>

General flow

This quick picture gives an overview of how we typically work if we develop a product from scratch.

<aside> 👉

Activities & Deliverables can vary based on the existing materials and state of the product.

For example, we can propose UX or Code audit if the product (or part of it) was already developed.

</aside>

What artifacts will you receive?

Project Scoping & Estimation

<aside> 💡 Scope, requirements and estimation

Product scope represents the list of features for the product - based on this document we plan releases

Requirements describe detailed rules for each feature: what the user should be able to do with the system and how the system should work

Estimation represents the efforts needed to deliver the scope of features based on defined requirements for them

</aside>

How do we calculate the pricing & time needed for your project ?

• Detalization of the features. The more we know, the more precise estimation we can give
  • More details
• Complexity of each feature → the more cases we want to cover, the more time we’ll need to develop & test it
• Technology stack → in case we use some new technologies, risky third-party integrations we will require more time on investigation and testing of them after implementation
• Product perfection level → sometimes to deliver fast MVP we can agree to have product with minor bugs or not pixel perfect, however, in some cases it can’t be the case from the beginning, so we need to have more time to test end ensure the quality
• Test coverage → for the MVP development where the scope can change a lot after the user feedback code can be covered by tests on later stages, however, in some cases tests are crucial from the beginning (this adds ~20% of time for each feature and then their maintenance as well)

Based on the defined scope, tech approach, estimation, team composition we create\update roadmap for development (read more about roadmap)