Patient portals and clinical tooling, built to be audited
Healthcare software gets judged in the ninety seconds a clinician has between patients, and again in an access audit two years later. Both matter. We build patient-facing and clinical applications where being correct and being legible count for more than being new.
What makes healthcare software hard
Before anything about us. These are the constraints that shape every healthcare build, and the reason generic delivery comes unstuck here.
Records you cannot afford to leak
Patient data needs encryption, least privilege, and an audit trail from the first commit. Adding access control to a product that already shipped means re-testing every screen and trusting that you found them all.
Four systems, four patient identifiers
Scheduling, records, labs, and billing were each bought separately, and each believes it owns the patient. Much of the work is deciding, on purpose, which one is right when they disagree.
Software used between patients
Clinical staff work in short bursts on shared workstations, get interrupted mid-task, and come back to a screen that has timed out. Dense, ambiguous layouts turn that into entry errors.
Healthcare capabilities
Four areas we take on in this sector. Each one is work we do rather than a category we list.
Portals people use while feeling unwell
Patients arrive on whatever device they own, usually after a phone call went unanswered. The portal has to work on a mid-range Android on mobile data, without a manual and without a second attempt.
- Appointment booking, changes, and cancellations
- Results and records access
- Secure messaging with the practice
- Intake and consent forms
- Reminders that do not become noise
- Tested on older phones and slow connections
Where these projects actually go wrong
The recurring failure patterns in this sector, what we do differently, and what that changes. You will not find a claimed figure here. Those belong to engagements we can name, and we do not name what we cannot evidence.
Scheduling, records, and billing hold the same patient under three different identifiers, so reception re-keys the same details into each one.
An integration layer that maps every system into one internal model, leaves the original as the source of truth, and queues conflicts for a person to settle.
One place to look, and disagreements between systems arrive as work items instead of drifting quietly.
Permissions were added after launch, so what a receptionist can see depends on which screen they happened to open.
Roles defined at architecture stage and enforced on the server, with every read and write attributable to a named user.
An access question gets answered from a log rather than reconstructed from memory.
Clinical screens are dense, every action looks like every other action, and staff use them while being spoken to.
Role-aware layouts showing only what that user needs, with destructive actions separated, confirmed, and reversible wherever the data model allows it.
Fewer available ways to make the wrong entry under time pressure.
Patients cannot see their own appointments, results, or messages without ringing the practice during opening hours.
A responsive portal covering booking, records, and secure messaging, tested on older devices and constrained connections rather than on office wifi.
Routine questions have somewhere to go other than the phone queue.
Commitments, not promises
How we build for healthcare clients. Each one is checkable in the work itself rather than a claim about results you cannot see.
Access control at architecture stage
Roles, permissions, and audit logging get drawn before the first screen. Every read and write is attributable to a named user.
Accessibility as acceptance criteria
Keyboard paths, focus order, contrast, and screen-reader labels are checked before a story closes, not queued into a remediation project.
Handover you can act on
Architecture notes, runbooks, and a local setup that works, so your team can change the system without ringing us first.
Three ways this usually starts
Prices are not listed because they depend on scope. We quote a range after discovery, along with the specific things that would move it toward each end.
Discovery
Best before you commit
A short paid engagement that ends with a scoped plan you own, whether or not we build it. If the honest answer is that you should not build software at all, that is what the document will say.
- Requirements and constraints captured
- Technical and integration assessment
- Architecture and approach outline
- An estimate as a range, with its drivers
- Risks named rather than implied
Project build
Best for a defined outcome
A scoped build with an agreed deliverable, run in short cycles with something you can review at the end of each one. Suited to work where the shape of the outcome is already clear.
- Fixed scope with a change process
- Something reviewable every cycle
- Design, build, test, and deploy
- Documentation and runbooks
- Handover to your team
Dedicated team
Best for an ongoing roadmap
A small team working continuously against your priorities, with capacity you can plan around. Suited to products that keep changing rather than projects that finish.
- Named engineers, consistent over time
- Priorities you set each cycle
- Direct access to the people building
- Shared repository and tooling
- Exit on notice, with no lock-in
What we tell clients before they add an LLM to their product
Most requests we get for AI features describe a solution rather than a problem. The useful first conversation is about what happens when the model is confidently wrong.
Most cloud migrations do not need a rewrite
The instinct to re-architect everything on the way to cloud is how a migration becomes a multi-year programme that stalls. Move it first. Then fix what the bill points at.
How we scope a project, and why we sometimes say no
A scoping call that ends in an honest no is worth more to both sides than an engagement that starts on a misunderstanding.
Healthcare: what buyers ask us
Including the ones where the answer is no. A limit stated up front is worth more than a capability claimed now and found out later.
Usually, if it exposes an API, an HL7 or FHIR interface, or a supported export. Our work sits alongside your system of record instead of replacing it. We map its data into an internal model, keep the original authoritative, and put a reconciliation queue wherever the two can disagree. If a system genuinely has no integration surface, you will hear that during scoping rather than in month three.
We do not develop against live patient data. Environments are separated, test data is synthetic or de-identified, and any access to something production-adjacent is limited, logged, and time-boxed. If you need a data processing agreement or an equivalent contract in place before work starts, raise it early. We expect that conversation and it does not slow anything down.
No, and treat any vendor who says yes with suspicion. Compliance is a programme you own and an assessor examines. Our part is building software that supports it: encryption, access control, audit logging, retention rules, and architecture documentation an assessor can actually read. We build to the controls your compliance function specifies, and we tell you when a requested feature makes one of those controls harder to hold.
Included, as acceptance criteria on the work itself. Keyboard paths, focus management, colour contrast, and screen-reader labelling get checked before a story closes. Retrofitting accessibility into a finished interface costs several times what building it in costs, and healthcare has an unusually wide range of users to begin with.
It depends almost entirely on how many systems it has to talk to, which is what we spend the scoping call on. You get a range and the specific things that would push it toward either end. A portal over one clean API and a portal over four systems and a nightly file drop are different projects wearing the same name.
You get architecture notes, runbooks, and a handover session, so your team can run the system without us. If you want us on support or an ongoing roadmap, that is a separate agreement. It should be a decision you make, not something the codebase forces on you.
Industries we work in
Fintech & Banking
Payment flows and the ops tooling behind them
E-commerce & Retail
Storefronts that load, checkouts that finish
Education
Learning platforms built by people who run one
Logistics
Tracking and field apps for teams without a signal
Real Estate
Listing platforms that are fast and findable
Manufacturing
Production visibility for the floor and the office
Insurance
Quote and claims flows that survive an interruption
Let's talk about your healthcare project
A scoping conversation costs nothing. You leave with a clear view of the approach, a budget range, and the main risks named out loud, including an honest no if we are not the right firm for this.