Building muscles and picking up the pace: web and mobile fitness app in 3 months. FitnessApp case study

Training at home but under supervision

Our clients — Tyler and Ben — are fitness-savvy guys. In November 2020, they requested that we make a fitness mobile app that would connect coaches with their clients. It was supposed to work this way in the app: clients can find a new coach or train with coaches who earlier worked with them in the gym.

The clients knew that we specialize in MVPs and we already had experience with fitness mobile app development — project FitForce.com. They liked the project and wanted to get something similar. We agreed on terms and started working. Our team consisted of nine specialists.

Meeting everyone’s needs: web app for coaches, mobile for clients

We developed FitnessApp from scratch. Our clients already had a website, but they were not satisfied with it. It was hard to organize the process of training and connecting coaches with clients through the website, but an app is a totally different matter.

To stay within the budget, we decided to split the project into two parts. The first part was a web version of the platform for coaches, and the second one — a mobile version for clients. In other words, the functionality differs for each role since we couldn’t do one version for both sides. That was the best use of resources.

1200 hours for everything? Well, maybe at least 2000?

And now, the most interesting part. I’ll tell you how we estimated the project in 1,200 hours, but then we realized that we overrated our forces but underrated the project.

In the beginning, we estimated the project to have all the features that should be included in the MVP — it turned out to be 1,200 hours. The number seemed real, and the clients were fine with the timeframes. We signed the documents and started off.

Developers and designers worked in parallel, and when the design was finished we realized that the quote was inaccurate — we needed more time. Our CTO, Sergey Ponomarev, found some risky moments in the quote and summed up that we needed 2,000 hours.

That’s why we scoped out some features in the scope and agreed to do them as separate tasks. The client accepted our arguments — after the design was finished, the situation became \clearer. Besides, the design adds extra features here and there, which is why deadlines increase unavoidably.

We continued to work with realistic timeframes and clear deadlines. And improved the estimation process for the future. Now, we have two rules:

1. Once the design is ready — we estimate the time and budget.
2. The team lead and CTO are involved in the estimation, and the process is eight times longer, but it’s one hundred to one done accurately.

What’s in the scope?

We discussed with the client all the features they certainly wanted to see in both app versions. For the coach’s side, these are:

• • client’s training schedule
  • ability to create fitness programs
  • info about clients, for example, what programs they are in
  • chats with clients

For the client’s side, these are:

• • chat with a coach
  • fitness program and exercises
  • notifications (about messages and training)
  • calendar of training

Initially, we wanted to add a motivation system in the MVP: users fill in all the metrics, see the progress, and get happy (or upset). But then we thought: do the users pay coaches, and do they need to monitor and do data entry manually? That’s why we decided to get back to the progress diagram later.

New and self-dependent design

Despite the fact that our client made mention of our previous sports project Fitforce.com, we decided not to copy it but use it as a reference. Besides, when we started working on the project, Fitforce was already a little old-fashioned.

In the design stage, we called our clients two times a week and showed them intermediate progress. We were getting feedback fast and making some edits right away.

What’s the difference between this project and Fitforce? The devil is in the details:

• • All the buttons in FitnessApp are in comfortable size for fingers. We strictly followed Apple’s guidelines.
  • The onboarding process in FitnessApp is optimized: users fill in personal data and body measurements on one screen.
  • In FitnessApp, the main color is purple, and the secondary color is pink.
  • Text on the cards is carried out on a white background, that’s why users can see it clearly.
  • In FitnessApp, all text color styles are well thought out. The main color is seen clearly and contrasts with secondary pink, which also improves readability.

Sometimes, in the design stage, it happens that a designer prepares all the screens, the client approves everything, and we hand it off to developers. But actually, it is hard to develop everything exactly as the designer projected. Some changes appear, and we have to adjust during the course of the project. We created a checklist of important things that can be forgotten in the design stage. At the start of the project, the developer checks that everything is done.

Web-, mobile-version, and testing in just 3 months

We didn’t want to spend much time on bug testing because we needed to meet the ambitious 1,200 hours. We planned our work this way:

1. We work from sprint to sprint;
2. Test in parallel with development;
3. At the end of every sprint, we devote two days to bug fixing;
4. After every sprint, we show a finished part of the project to the client;
5. Every second sprint, we do regression testing — we make sure that the features from previous scripts work steadily.

This way, every sprint was ready for demonstration to the client straight after its realization, and we didn’t have to spend eternity fixing bugs at the end of the project. Thanks to this, we managed to finish in three months.

The development was organized this way:

1. Authorization, front-end and backend architectures, HTML coding;
2. All the features associated with training, calendar;
3. Chat and push notifications;
4. The connection between client and coach = connection between the web service and the mobile app;
5. Videos.

We decided to choose typescript as a programming language. Typescript is strongly typed, that’s why developers have less freedom of action, which leads to fewer bugs. The mobile app was built on React Native, the web — on React, and the backend was written on Node.js using the nest.js framework — it is convenient to write isolated modules and then use it in other client’s projects if necessary. That’s our standard tech stack.

A little help from external services

To meet the deadline, we decided to implement a part of the functionality with the help of external services. We often do it when working on MVPs to keep within budget and meet deadlines. We used:

1. Vercel for fast testing;
2. Vimeo for videos;
3. S3 for storage;
4. Auth0 for authorization;
5. Stripe for payments;
6. Pusher for chat;
7. Firebase for push notifications.

Ready-made solutions take only one-fifth of all code. For example, you can write custom authorization and spend 25 hours on it, but with a service, you can do it in five hours.

What now?

We made features that were not included in the scope of MVP and published the app in the AppStore. What did we do?

1. Training plans (programmes with exercises);
2. Ability to send invites to clients registered in the app.

After release, we test the project with our internal team to make sure everything works well in the production stage. We have met the 1200-hour time frame although we had to carry some features out of the initial scope. However, we agreed with the client about it and could prove why these features should be realized separately. This project turned out to be a good ‘material’ for setting and improving our processes.