Things I have built, with their actual status.

Getting to a clinic often means not knowing which one is open, how far it is, or what to do first. Paper records go missing between visits, so each consultation starts from nothing. In an emergency there is no fast path to the right contact.

A mobile health application for Cameroon. The audience is general public rather than clinicians, which sets the bar for how much the app is allowed to assert about someone's health.

• Lower-end Android devices, so the minimum supported API level is 21 and payload weight is a real budget rather than a nice-to-have.
• Intermittent connectivity, so anything that assumes a live request will fail in the field.
• Health data, which changes what is acceptable to log, cache and retain.
• A single engineer, so anything clever has to be maintainable by one person months later.

Technical build across the Flutter client and the PHP API — architecture, implementation, the design system, the test suite, and the CI setup.

Feature-first module layout rather than layer-first. Auth, profile, health records, reminders, notifications, clinic locator and emergency each own their own state through Provider, with go_router handling navigation between them.

Behind that, three domains — auth, profile and health records — sit behind a repository abstraction with typed API models, so the call sites do not know or care whether data came from the network or a local store.

• Rule-based triage, not a model. A decision tree over documented symptom paths. Every branch is reviewable by someone who is not an engineer, and the app can explain exactly why it said what it said. A classifier would have been easier to build and impossible to defend.
• Repository abstraction before the offline work. Introduced while the app was still online-only, specifically so the offline layer can slot in underneath without rewriting the feature modules.
• Tonal elevation instead of drop shadows. The design system uses surface tone to express depth because soft shadows band badly on low-cost LCD panels.
• Build-time API base URL. Environments are a build flag, not a runtime toggle, so a debug endpoint cannot ship in a release build.

Flutter and Dart on the client, PHP on the server, REST between them with JWT for session handling. A custom design system — Clinical Sanctuary — fixes the palette, an 8pt spacing grid, and the type scale, so screens stay consistent without a component library.

Built and working in the codebase: authentication, profile management, health records, reminders, notifications, clinic locator, emergency contacts, the emergency portal, and the rule-based symptom checker.

88 automated tests — 72 in Flutter, 16 on the PHP API. CI runs lint and the full suite and blocks a merge if either fails, so the gate is enforced rather than aspirational.

The repository also carries an architecture document, a deployment runbook and a risk register, which matters more than it sounds: the runbook is what makes the deployment reproducible by someone who is not me.

• Server-side login rate limiting, so throttling cannot be bypassed by talking to the API directly.
• JWT revocation, so a compromised session can be ended server-side rather than waiting for expiry.
• Password reset backed by a proper token table.
• Secrets moved out of source and into build configuration.
• Bounded queries — health records and reminders are capped rather than unbounded — so a large account cannot degrade the API for everyone else.

• Rule-based triage is narrower than a model and has to be extended by hand. That is the cost of being able to explain it.
• A hand-rolled design system means no ecosystem of ready components, in exchange for control over rendering on cheap panels.
• PHP was the pragmatic server choice for the environment rather than the interesting one; the repository abstraction is partly insurance against that decision.

In development. The feature set above is implemented in the codebase, but the application has not been deployed and is not in front of patients. A migration-readiness review for moving the backend to Laravel returned not yet, with three gates still outstanding.

Scoped but deliberately not implemented: a QR emergency health passport, AI health companion mapping, and a further privacy and security pass. None of these exist yet, and the app does not behave as though they do.

Clear the three migration gates, add crash reporting and structured logging, then move to a real HTTPS deployment with scheduled database backups — in that order, because there is no point collecting crash data from an environment that is not yet reproducible.

The abstraction I am most glad about is the one I added before I needed it. The one I underestimated is documentation: the runbook and risk register took an afternoon each and are the only reason the deployment path is legible now.

The harder lesson was scope. Health software makes it very easy to promise interpretation, and most of the engineering discipline here went into deciding what the app is not allowed to claim.