Case Study · Wellness & Healthtech
A chronic-illness companion app rebuilt to grow
A newly funded German health startup had an app its team could no longer build on, and a roadmap that kept growing: medication, symptoms, wearables, exercise programmes. We rebuilt it from inside their team, on one structure that takes each new feature without starting over, and carried the product since 2025.
Germany
Healthcare · Chronic illness
Custom app · Rebuild
iPhone & Android, one shared codebase
Client stage
Newly funded health startup with its own tech team
Fifteen to twenty people and a CTO, with a first version of the app that could not carry what they planned next.
Engagement
Rebuild, then ongoing product partner, since 2025
A rebuild and development, that is still running today
3,000+
Monthly active users
People managing a long-term condition who open the app every month, as reported by the client.
6 areas
On one patient record
Medication, symptoms, calendar, exercise programmes, wearable data and assessments, all reading from the same data.
Since 2025
On the product, and still shipping
From the rebuild inside the client's team to Applify Lab as their product team today.
The client
A German health technology startup building a daily companion app for people living with chronic illness, including Long COVID, ME/CFS, fibromyalgia and rheumatoid arthritis.
These are conditions where symptoms change from day to day, treatment involves several medications, and progress is measured over months rather than visits. The app gives patients one place to record what they take, how they feel and what they do, so the picture is there when they need it. When the rebuild started, the company had just raised funding, employed fifteen to twenty people and had its own CTO. The decision to rebuild was taken by the CTO and the COO.
The situation
The funding gave the company a plan. The existing app stood between them and it, for three reasons.
Two apps, one productAn app the team could not build on
The first version had grown without a structure behind it. It was hard to maintain, it broke in ways that were difficult to trace, and every change risked something else. With a product roadmap ahead, patching it would have meant paying that cost again on every feature.
A roadmap much longer than one release
Medication, symptoms, a calendar, exercise programmes, wearable data and clinical assessments were all coming. The brief, in the client's own words, was a maintainable and extensible app: one that could take each of those without being rebuilt again a year later.
A team that had to own it afterwards
The company had its own developers and wanted to keep them. Moving to new technology only works if the people who maintain the app understand it, so the rebuild also had to bring the existing team along with it.
How we approached it
The work that mattered most here is the part a user never sees: deciding how the app is put together before deciding what goes on the screens.
1
The structure came before the features
The hardest part of the project was designing an app that could hold a long list of features and stay maintainable. So the rebuild started there: one patient record at the centre, and each area of the app, from medication to wearables, built as its own part on top of it.
That is what lets a new area join the product later without touching the ones already working, and what keeps the app understandable for the next developer who opens it.
2
We worked from inside the client's team
We rebuilt the app alongside its CTO and developers rather than handing over a finished product from outside. The new technology became the team's own as it was built, which was half of what the client asked for.
3
The client's experts create the content, not the developers
Exercise programmes and courses change more often than code should. We built an engine for them, so the client's own team can create an exercise or a course and offer it to the patients whose condition it fits, without a release.
4
The same people stayed on the product
The people who designed the structure are the ones still extending it, which is why new features keep landing in the places they were planned for.
What we built
Six areas, on one patient record, on iPhone and Android.
Daily tracking
Medication and symptoms
Patients add each medication and log every intake
Reminders set for when each dose is due
Symptom tracking, such as headaches, logged as they happen
A history of data points over time, so patterns become visible
Planning the day
Calendar, to-dos and appointments
Everything a patient did on a given day, in one view
To-dos tracked inside the app
Medical appointments kept alongside the rest of the day
Treatment content
Exercise and course engine
Internal tool for the client's team to create exercises and courses
Custom programmes offered to patients according to their condition
New content published without a new app release
Connected data
Wearables and assessments
Connections to Apple Watch, Garmin and Google's health data
Sleep, steps and activity collected and processed into the patient record
Scientific assessments patients take to understand where their condition stands
Secure login and push notifications across both platforms
Medication tracking is the part that cannot be approximately right. A reminder that arrives late, twice or not at all is a missed or doubled dose for someone managing several treatments. It was one of the two hardest parts of the build, and it was treated that way.
Wearable data only helps if it is read correctly. Each device and platform reports sleep and activity in its own way. Collecting it and processing it into one consistent record is what turns three data sources into one picture of how a patient is doing.
The first screen a new patient sees, with the app's promise in one sentence: keep track of your health.
At sign-up, patients choose their conditions, so programmes and content match them from day one.
The results
More than 3,000 monthly active users
People living with chronic illness using the app every month.
Fewer crashes, better performance
The client's own comparison with the version the rebuild replaced.
Six areas on one structure
From medication to wearables, each one added on the same patient record rather than as a separate build.
Live on iPhone and Android
The same tracking, programmes and wearable data on both platforms.
Content the client runs themselves
Exercises and courses created by the client's team and matched to each patient's condition.
A partner who stayed
On the product since 2025, and still shipping today.
If you’re building something similar
Very little of what made this project hard is specific to one condition. If any of these describe your product, it is the same work with different screens.
A patient app with daily tracking
Medication, symptoms, mood or pain, logged by patients and read over months.
A programme your experts create
Physiotherapy, rehabilitation, mental health or coaching content that your team publishes and assigns, without a developer for each change.
An app that reads wearable data
Sleep, steps and activity from smartwatches and phones, turned into something a patient or a clinic can use.
A first version that can't carry your roadmap
n app that works today but breaks with every new feature, and a team that needs it rebuilt on something it can own.
Questions people ask us
Before you build something like this
What does it cost to run once it's built?
Running cost comes from four places: hosting and data storage, the outside services the app depends on (login, notifications, wearable connections), app store and compliance overheads, and the pace at which you keep adding features. An app built on a clear structure keeps the last one predictable, because new features don't mean reworking old ones. We size all four with you before the build, not after it.
Should we rebuild our app or keep fixing it?
It depends on what you plan next. If the roadmap is short, fixing the current app is often cheaper. If every new feature breaks something else and a long roadmap is coming, rebuilding the foundation once usually costs less than paying for that fragility on every release. We look at the code and the roadmap together before recommending either.
Can a health app connect to Apple Watch, Garmin and Google's health data?
Yes. This app collects sleep, steps and activity from all three. The work is less in connecting them than in processing what they send, because each one reports data differently, and the patient record has to show one consistent picture regardless of the device.
Can our own team keep working on the app after you build it?
Yes, and here it was part of the brief. The app was rebuilt alongside the client's own developers, so the structure and the technology were theirs from the start, and the code belongs to the client. Some teams take the product fully in-house; this one chose to keep us on as their product team.
What happens after launch?
A health app is never finished: conditions, content and devices keep changing. Most clients continue with us on a monthly partnership, where each sprint is scoped and agreed before it starts. This product has kept adding features since the rebuild, on the same structure.
Building a patient app?
Message us on WhatsApp. We'll tell you whether we're the right team for it, and what the first phase would need to cover.
More of our work
Other builds in this space
Case Study · Wellness & Healthtech
A GCC wellness marketplace, live on both stores in eight weeks
CASE STUDY · RETAIL & E-COMMERCE
