We care about product delivery and we will maximally involve you to the development process to make it happen with greater pace and top-notch quality. We dream big and aim high. And once committed — WE DELIVER!
Chili Labs teams are facilitated by certified Alliance© Scrum Masters and following the best Agile / Scrum practises. We have gathered a unique expertise in delivering complex, world-class, online and offline products. People in Chili Labs are embracing changes & meetings for constant team improvements.
1. Project start
Before we grab a project - we investigate available materials and resources, get all the possible information about the project, business and people we will work with. Always asking crucial for project engagement questions and details, get familiar with clients business.
How they are making money? Is that a huge project to them, side project or just an experiment. Will it impact their current business?
Why do we need to know this?
It determines how involved the client is, how much of the time / effort they will dedicate to us. The more responsive client is, the better success app has! We believe it should be meaningful to both parties, as even from our best intentions without involvement from the client there is no success.
2. Scoping the project
Based on all of the information above we create a ballpark (very rough) estimate of the planned functionality.
The main idea is to split all the development functionality into small parts and estimate them separately. It’s valuable — because we better understand the product you are about to create and by breaking down the project scope and understand on what the technical difficulties are ahead.
From the client side - it gives you the idea on studio overall pricing (what part of the app costs what). Helps you to compare studio with competitors and ensures that you can reevaluate the scope and remove some functionality, which means — reducing the price!
Development can almost always be split into separate modules. Therefore, it allows to remove/add functionality.
We always encourage clients to have MVP first. It’s always a safe option to have. You don’t risk that much money at the start of a project and can test, if your idea/app is viable. Remove unnecessary functionality from the estimate, to reduce the price — like: Two-factor authorization, FaceID, TouchID, etc., it can be added to the app later on and would not affect the app itself. Later on, when you realised that the idea is working, we can add development tempo and extra hands to catch up and make even better results in development the project for you.
3. Understanding the project
Without proper specification there is very low chance that you will receive correct result. Either you are working with Agile methodology, with rapid changing of a scope, or we create a detailed technical documentation on what actually should be delivered by us to you.
3.1. Drawing the map:
The first step would be to draw functionality or a “mind map”. The goal is to put all the possible transitions, screens, states and events on a whiteboard. It’s done to make sure we haven’t forgotten anything. You can clearly see all the navigation and logical components/epics of the upcoming app. It also helps you to entirely understand the app, whether there are some strange moments and bad transitions / missing screens, etc.Bullets + image of xmind:
3.2. Specification document:
Based on visual functionality map, we create a document with detailed technical specifications:
The purpose for Gantt chart is to understand the development plan on a timeline. For Agile projects — you should still create a timeline for project delivery. It can be done by sprints planned (usually sprints are done by modules / interconnected functionality). For Kanban projects (support projects) — Usually there is no need to draw a timeline, however, if it’s needed — you can use release versions to put milestones on a timeline.