Health and Wellness Mobile App Development Case Study

An integrated team can keep moving by deciding what the existing requirements already answer and bringing only the genuine open questions back to the client. That is what happened on a recent mobile app project for a health and wellness company, and the client's internal satisfaction score held above 4 throughout.

When a client's input slows down in the middle of a project, delivery does not have to stall. An integrated team can keep moving by deciding what the existing requirements already answer and bringing only the genuine open questions back to the client. That is what happened on a recent mobile app project for a health and wellness company, and the client's internal satisfaction score held above 4 throughout.

linkAt a glance

• Sector: health and wellness, running personalized health programs supported by call-center agents.
• Engagement: a new mobile app to guide users through their personalized health programs. Four-month project, with final delivery still ahead.
• The constraint: during some critical periods, the client's product owner was not available to answer the questions needed to keep moving.
• What we did: the team took ownership of the open questions. QA compared the Figma design (the team's primary reference), the client's guide and the app, resolving what the requirements already answered and bringing only the genuine open questions back to the client.
• Result so far: the project stayed on track, the client confirmed the team's direction and added improvements beyond what had been expected, and the internal satisfaction score stayed above 4, reaching 4.7 out of 5.

linkThe constraint: the project could not wait on one set of answers

On most projects, one person on the client side holds the context and the sign-off for direction. On this one, that product owner was unavailable during some critical periods, while the delivery date and budget stayed fixed. Two easy paths were both bad. Pausing the work would cost time the schedule did not have. Building on guesses would risk rework and a product that did not match what the client asked for. The team looked for a third path: how much it could responsibly decide from what the client had already documented.

linkThe response: ownership first, QA as the method

The team did not stop at the edge of each person's role.

• The team's primary reference for the app was the Figma design. The PM studied the client's program guide closely, the paper version of the health program, to keep decisions grounded in the content and experience the app had to carry into digital.
• Our QA specialist compared three artifacts that can drift apart: the Figma design, the client's program guide and the current app. He documented the inconsistencies the team found, which turned a vague blocker into a concrete list: what the existing requirements already answered, and what genuinely needed the client's input.
• For example, the guide restricts certain supplements to specific times of day, but the approved Figma design let users log any supplement at any time, and the build followed the design. QA caught it by comparing the guide's rules against the design and the app: as built, a user could log a supplement at a time of day the guide does not allow for it, which could contradict the app's own content and the instructions shipped with the supplements. The team flagged it to align the app with the guide rather than ship the design as-is.
• The team resolved the first group itself, grounding each decision in the client's written guide and the priorities stated in earlier sessions.
• For the open questions, the team prepared a short, specific list, so when the client was available, alignment was quick and focused.
• The guide-alignment items and the improvements the client requested were tracked in a single epic of 18 tickets, drawn from demos, client emails and guide reviews, so the open items stayed organized while the client was unavailable.

The team also reviewed earlier client sessions, using AI-assisted analysis to spot recurring patterns in the client's feedback and keep decisions aligned with what had already been discussed.

linkThe result so far

• The project kept moving through the periods of limited availability, without pausing and without building on guesses. Final delivery is still ahead.
• When the client was available again, the client confirmed the team's direction and added improvements beyond what had been expected.
• The engagement holds an internal client-satisfaction score of 4.7 out of 5. This is a NetForemost measure, rated by the client each sprint, and it has stayed above 4 across the four-month project.

linkWhat we took from it

• Involve QA earlier. Our QA specialist's own takeaway was that bringing QA in during design definition, while the Figma is still being created, would surface inconsistencies before development starts, not during it.
• Ownership moved the work. The project kept moving because the team treated its outcome as its own, rather than stopping at the boundary of each role when the usual answers were slow to arrive.