BYTERIGHT

Case study 03 · Healthcare

Intelligent health technology platform

An operational platform for preventive-health programmes — scheduling, partners and intelligence — without pretending to be a clinical device.

Challenge
Programmes lived in calendars, chats and disconnected tools. Follow-up depended on heroic operators. Intelligence existed as a slide, not a production path.
Architecture
Programme, scheduling and partner-workflow services, with an intelligence layer consumed through the same gated APIs as the product — not a sidecar chatbot.
Engineering
Consent and least-privilege access as defaults, human review on automated follow-up, and evaluation of recommendations against operational outcomes rather than demo prompts.
Outcome
Coaches and operators worked from one system. Intelligence supported follow-up without becoming a treatment claim. Programmes could be run as infrastructure, not campaigns.

Problem

A preventive-health organisation was trying to run programmes across communities and workplaces with tools that were never designed to be operated: calendars, messaging apps, spreadsheets. Specialists were strong; the system around them was not. Leadership wanted “AI”. Operators wanted follow-ups that actually happened.

Context

This is clinical-adjacent work, not a medical device. The system coordinates people, schedules, partners and participation. Health-related data still has to be handled with care: access, retention, audit and a clear line between operational intelligence and clinical advice. The architecture had to respect that line.

Users

Coaches and specialists who need a schedule, a roster and a way to follow up. Operators who keep programmes alive after launch. Programme leads who need an honest picture of participation. Participants who should feel a human system, not a surveillance product.

Constraints

Privacy and consent are design inputs. Automated messages cannot invent clinical guidance. Recommendations need a fallback when the model is wrong or the data is stale. Programmes run on real-life calendars — apartments, workplaces, evening slots — so the software has to encode exceptions, not only a weekly template.

Architecture

Programme, scheduling, partner and participant services behind a single product surface. Intelligence — next-best follow-up, risk of drop-off, workload for a coach — is a service consumed through the same API gateway as everything else, with auth, audit and a human-review step. There is no free-floating chatbot with access to the database.

Technology

A workflow-shaped domain model, not a content site with a model bolted on. Feature and event data for operational predictions. Retrieval and tools only inside defined boundaries. Evaluation sets drawn from real programme outcomes. Observability on whether a follow-up was suggested, approved, sent and completed.

Engineering challenges

Keeping intelligence useful without over-claiming. Preventing prompt or tool access from becoming a data leak. Designing human review so it is a path, not a bottleneck that operators skip. Handling no-shows, substitutions and cancelled slots as first-class events. Making the system calm enough that people will actually use it every week.

Solution

We built the operational system first — programmes, schedules, partners, a console operators can live in — then attached intelligence to a specific workflow: who needs a follow-up, and what the next human action is. Automation drafts; a person sends. Models are evaluated against whether participation holds, not against how clever the copy sounds.

Outcome

Programmes stopped living in side channels. Coaches and operators shared one picture of the week. Intelligence became a production path with oversight, not a demo. The organisation could run preventive health as infrastructure — calendars, follow-ups and care that show up after the launch video ends.

Lessons

Health-adjacent software fails when it pretends to be a clinician or when it ignores operators. Intelligence has to sit behind the same gates as the rest of the product. The first “AI feature” should be a workflow with a fallback, not a chat window. Trust is earned in the Tuesday evening slot, not in the architecture review.

Next

Let's build what comes next.

Have a product to build, a platform to modernize, or a complex technology problem to solve?