Healthcare & diagnostics
Clinical data that reaches the patient without losing its protections
Diagnostics software has two audiences with opposite needs: clinicians who want completeness, and patients who want to understand one result. Building for both, under real encryption requirements, is the whole problem.
What the work is up against
01
Access is geographic as much as technical
Patients in remote regions need booking and results to work on a modest phone over an unreliable connection.
02
Reports must be secure end to end
Health data encryption is not a feature to be added later. It constrains the architecture from the first decision.
03
Results are unreadable to the people receiving them
A pathology report written for a clinician leaves a patient no better informed. Interpretation has to be designed, not appended.
What we build for healthtech teams
Mobile-first booking and delivery
Test booking and report delivery designed for a modest phone on an unreliable connection, which is the actual device profile in the regions being served.
End-to-end encrypted health data
HIPAA-aligned architecture where encryption shapes the data model from the first decision rather than being layered on before launch.
Patient-readable result interfaces
Presentation designed for the person receiving the result, not only for the clinician who produced it.
In-app clinical consultation
Direct doctor-consulting flows in the same application, so an unclear result has an immediate route to explanation.
Location-aware scheduling
Collection and lab scheduling that accounts for where the patient actually is, which is the difference between a booking and a completed test.
How we approach it
Two audiences, opposite needs
Clinicians want completeness; patients want one result they can act on. Building Homelab meant refusing to compromise into a single view that served neither, and instead designing the patient path deliberately.
Encryption is an architectural constraint
End-to-end protection of health data determines how records are stored, cached and synced. Treated as a late addition it forces a rewrite; treated as a starting constraint it costs very little.
Access is a bandwidth problem
Reaching patients in remote regions is less about feature set than about payload size and offline tolerance. Mobile-first here meant designing for the worst connection in the service area, not the average one.
Delivered work
Homelab — India
A pathology lab test booking and digital report delivery system built for patients in remote regions.
- Active users
- 50k+Active users
- Encrypted report delivery
- End-to-endEncrypted report delivery
- Built for low-bandwidth regions
- Mobile-firstBuilt for low-bandwidth regions
Questions we get from healthtech teams
- How do you handle health data compliance?
- Encryption is treated as an architectural constraint from the first decision, not a layer added before launch. It determines how records are stored, cached and synchronised. Retrofitted onto a finished system it forces a rewrite; designed in from the start it costs very little.
- Can patients in low-connectivity regions actually use it?
- That is the design target rather than an edge case. Mobile-first here means designing for the worst connection in the service area — payload size and offline tolerance matter more than feature count. The Homelab platform serves patients in remote regions on modest devices.
- Do you build for clinicians or for patients?
- Both, without compromising into a single view that serves neither. Clinicians want completeness; patients want one result they can act on. Those are separate interfaces over the same record, and the patient path has to be designed deliberately rather than derived from the clinical one.
- Does this integrate with existing lab systems?
- Typically yes — booking and reporting sit in front of laboratory information systems rather than replacing them. Location-aware scheduling is usually where the integration work concentrates.