Building a Multiple Sclerosis Management Platform from Scratch
Industry
Health Technology
Company size
1 - 10 Employees
About
The Situation
A Sydney-based health technology startup was building a platform to help people living with multiple sclerosis manage their condition. The concept was specific and valuable: a mobile app and web portal that allowed patients to track symptoms, log medication, monitor fatigue patterns, and share structured data with their treating clinicians.
The founders had deep domain expertise — one came from a clinical background, the other from health administration. What they didn’t have was a technology delivery capability.
The platform needed to be built from the ground up: a mobile app for patients across iOS and Android, a web portal for clinicians, an API layer connecting the two, and secure cloud infrastructure that met healthcare data standards. The scope was meaningful. The budget was fixed. The founders were time-poor and operating in a regulated space where getting things wrong had real consequences.
The structural challenge: the founders needed a delivery partner who could own end-to-end technical execution — not just write code, but make architecture decisions, manage compliance considerations, and keep the build oriented toward what patients and clinicians actually needed.
Key Result Metric: A working, live platform — web portal and mobile app — that could be placed in front of users, iterated on, and moved toward commercial partnerships with clinics and MS societies.
Why they called us
The founders found Halcrow through network referral. They had spoken to other development agencies. The difference they described in early conversations was orientation: most agencies they spoke to were focused on what they’d build; Halcrow was focused on what the platform needed to do and for whom.
The engagement scope was genuinely complex. Healthcare data handling, multi-platform delivery, clinical user experience design, and a budget that required disciplined scope management — none of these problems are solved by writing code faster. They are solved by making good structural decisions early.
Law 1: Start with the objective, not the solution. A multiple sclerosis management app is not a feature list. It is a set of outcomes for patients who are managing a progressive and fatiguing condition. The decisions about what to build first needed to be grounded in that reality.
How we worked
Embedded System: Full-Stack Delivery Team + Clinical UX Design
We embedded a full-stack delivery team covering frontend across mobile and web, backend engineering, and QA — with product management sitting inside our team from day one, not at arm’s length. The founders remained close to clinical and domain decisions; we owned technical execution.
The operating rhythm used regular sprint cycles with staged build releases — staging first, then production after client sign-off. Release notes communicated clearly to the founders at every production push. No surprises.
Decision proximity mattered. The founders had direct access to the engineering team. When clinician feedback came in, it moved quickly to the backlog without a gatekeeping layer. When the team identified a technical decision with compliance implications, it was raised directly rather than built around.
Phase 1: Architecture and Core Patient App
The first decisions were foundational: cloud infrastructure on AWS, a secure API design that could support both the mobile app and web portal from the same backend, and a data model that structured symptom tracking in a way that would be clinically meaningful rather than just technically convenient.
The patient mobile app focused on core daily functions: symptom logging, fatigue tracking, medication reminders, and a daily diary structure that built a longitudinal record over time. The design prioritised low cognitive load, because MS-related fatigue affects users’ capacity to interact with complex interfaces.
Phase 2: Web Portal for Clinicians
The clinician-facing web portal was built as a separate surface, connecting to the same backend. Clinicians could view their patients’ longitudinal data, identify patterns, and communicate with patients through the platform.
The architecture required careful API design to ensure the right data was accessible to the right user type without creating security vulnerabilities.
Phase 3: App Store Submission and Live Release
The app was submitted to both the Apple App Store and Google Play under the client’s developer accounts. Live release — a genuine milestone for a health tech startup — was achieved with V1.0.0 going to production.
The budget overrun signal reflected a pattern common in health technology builds: scope complexity grows as regulatory considerations and clinical user feedback sharpen what is actually needed. The team managed this transparently rather than building silently and presenting the founders with a fait accompli.
WHAT CHANGED
The platform went from a concept in the founders’ heads to a live, downloadable product on both major app stores. Patients could log, track, and build a longitudinal health record. Clinicians had a portal to engage with that data.
For the founders, having a live product changed the conversation they could have with clinical partners and MS societies. A deck describes what you might build. A working app demonstrates what you have built.
WHY THIS WORKED
Healthcare applications fail when the delivery team treats clinical context as a constraint to work around rather than the primary design input. The patient population here — people managing a progressive neurological condition — has specific needs that are not served by generic health app patterns.
The team stayed close to the founders’ clinical expertise throughout. When design questions arose that touched on how patients with MS actually experience fatigue, or how clinicians use longitudinal data in consultations, those were not engineering questions. They were domain questions, and the right people answered them.
Law 3: Keep decision authority close to the work. In a domain as specific as clinical health technology, the people who understand the users need to be inside the delivery process, not consulted at review gates.
what you're buying
This case study is published without the names of the client, founders, or product at the client’s request. The project details, build structure, and outcomes are accurate.
If you are building in the health technology space and want to understand how Halcrow approaches clinical user experience, regulated data handling, and multi-platform delivery, book a 20-minute call.