The piece nobody sells.
Every protocol eventually needs a piece of software that does not exist: a participant app with the right reminder logic, a screening tool for the emergency department, a clinician dashboard, a study website people actually trust, an ingestion service for a wearable nobody has heard of. We build those — and they feed the database you already have.
Most research software is written by a PhD student who then graduates. It works, until the day somebody needs to change one thing.
The student did nothing wrong. They were asked to deliver production software as a side quest, with no budget line or review, and nobody planned for the day they would leave.
We build the small piece properly: engineered, tested, accessible, documented, and handed over as source code your institution owns. It is usually a much smaller job than people fear. Most of what a protocol needs is a matter of weeks.
And we build it to feed what you already run. A new app that becomes a twelfth data island makes your study worse.
Built for the person holding the phone.
A participant app works only if opening it is easier than ignoring it. That means short tasks, honest progress, no login they have to remember, and never asking twice for something the study already knows.
Everything on that screen writes back to your database. The PROM answer lands as a REDCap record, the wearable sync lands as a timestamped row with a gap flag, and the completion status shows up in your coordinator's dashboard the same minute.
- Offline first. Answers survive a basement with no signal
- Accessible. WCAG 2.2 AA, screen-reader tested, large-type mode
- Translated by people, with the translation done as part of the build
- In the stores under your name, with the review process handled by us
Software the size of a protocol.
The study, in a pocket
Native iOS and Android from one codebase, with task scheduling, notifications, offline capture, e-consent and device pairing — published under your institution's developer account.
- App Store and Play review handled by us
- Passwordless entry — no credential your participants will lose
- Writes to REDCap or COHORT, never to a private silo
From first visit to screening submission
A public site that explains the study in plain language, answers the questions people actually have, and converts interest into a screening submission.
- Ethics-approved wording, in every language you recruit in
- Fast on a phone, accessible, no cookie banner theatre
- Recruitment source tracked so you know what worked
Eligibility, in ninety seconds
Tools for the people doing the recruiting: an emergency-department screening form that works on a shared tablet, a clinic pre-screen, a referral portal for other departments.
- Eligibility logic from the protocol, evaluated live
- Screening log kept automatically for the CONSORT diagram
- Works for the busiest person in the building
Live numbers for your steering committee
Recruitment by site, data completeness by participant, query ageing, safety signals — live, and without somebody rebuilding a spreadsheet every Monday morning.
- Role-aware: sites see themselves, the sponsor sees everything
- Blinding respected in every view
- Exports that match what the screen showed
Sensors that produce analysable data
Ingestion for activity bands, continuous glucose monitors, spirometers, blood pressure cuffs, ECG patches and the research-grade device that came with an SDK from 2019.
- Gap detection and wear-time validation as first-class output
- Raw data retained; derived variables versioned
- Missing days recorded as missing, never interpolated silently
Connecting systems that do not talk to each other
Bridges between your database, the hospital record, the lab, the biobank, the imaging archive and the national registry — built to fail loudly rather than silently.
- HL7, FHIR, REDCap API, SFTP and the bespoke CSV nobody documented
- Reconciliation reports on every run
- Monitoring that pages a human when a feed stops
Your participants are not all like you
Accessibility and translation are built in from the start: screen-reader tested, large type, high contrast, plain language, right-to-left where needed.
- WCAG 2.2 AA with a written conformance statement
- Human translation, reviewed by a clinician in that language
- Tested with older devices and older participants
Still running after the grant ends
Source code, documentation, deployment scripts and a runbook — plus an optional maintenance agreement for the operating-system updates that keep arriving after the funding ends.
- Your repository, your accounts, your app store listing
- Documented so another team can take it over
- Maintenance priced per year, cancellable
Yours, in a form you can actually use.
Research software fails at handover more often than at launch. So the handover artefacts are written as the build proceeds, in your repository, from the first commit. If we disappeared tomorrow, another team could pick this up next week.
The commercial reason we do this is straightforward: groups who are not locked in come back. The engineering reason is better — code that has to be explainable to a stranger ends up simpler.
- Your accounts, your repository — we work inside your organisation
- No proprietary runtime in the delivery path
- A runbook a stranger can follow — tested by having one follow it
- Source code in your Git organisation, with history
- Build and deployment scripts that run from a clean machine
- Architecture note — what it is, why it is that shape, what to be careful with
- API documentation for every integration point
- Test suite — unit, integration and the accessibility checks
- Runbook — deploy, roll back, rotate a secret, restore a backup
- Accessibility conformance statement with the exceptions listed
- Store listings and screenshots, in your developer account
- Data flow diagram for your DPIA
- A named engineer who answers for the first three months
Something usable in week three.
Working software your coordinators can put in front of two real people. Everything after that is informed by what those two people did with it, which is the only reliable way we know to build software for a population we are not part of.
Scope
We work out what the protocol requires, what the participant will tolerate, and where the two disagree, because that disagreement is what the design has to solve.
- Task list and schedule
- Data model agreed
- Fixed price, fixed date
Design
Screens drawn and reviewed with a coordinator and, where possible, a patient representative — before any code exists.
- Clickable prototype
- Plain-language copy drafted
- Accessibility decided now
First real version
Working software with the core loop, writing to a test project in your database. It is still rough, but it is in somebody's hands.
- Two real users try it
- Findings drive week 4
- Nothing is precious yet
Build out
The rest of the tasks, notifications, offline handling, translations, device integration, and the accessibility pass with real assistive technology.
- Weekly build you can install
- Translations reviewed
- Security review before release
Release & hand over
Store submission, production deployment, runbook, training, and the handover documents that make the codebase somebody else's to run.
- Store review handled
- Runbook tested by a stranger
- Named engineer for 3 months
Boring technology, on purpose.
A study runs for years, so we choose a stack that will still have security updates and developers you can hire in five years' time. Where you already have a stack and a team, we work in yours.
- Mobile
- React Native or Flutter for one codebase across iOS and Android; native Swift or Kotlin where a device SDK or a background sensor requires it. Published under your developer account.
- Web
- TypeScript with a mainstream framework, server-rendered where it helps the first load. Static hosting for study websites, so a recruitment surge is not an outage.
- Backend
- Node or Python with PostgreSQL: boring, well-documented tools your institution's IT department has met before.
- Hosting
- Your own infrastructure, one of our datacentres, a partner datacentre in Denmark or Germany, a partner datacentre in the United States where that is appropriate, or public cloud. Containerised, so the choice can change later without a rewrite.
- Integration
- REDCap API, FHIR where the hospital exposes it, SFTP and message queues where it does not. Every feed monitored, with an alert to a human when it stops.
- Accessibility
- WCAG 2.2 AA as an acceptance criterion, automated checks in the pipeline, and a manual pass with VoiceOver and TalkBack before release.
- Security
- Dependency scanning in the pipeline, secrets in a managed store, penetration testing before a public launch, and an update path for the years after go-live.
- Analytics
- Self-hosted and privacy-preserving, or none at all. A study app never contains third-party trackers; we treat that as a condition of the work.
What people ask before committing.
Can a grant pay for this, and how do we budget it?
Yes, and it is easier when the line item exists before submission. We provide a costed work package with a fixed fee, a delivery schedule and the maintenance cost for the years after launch — which is the number reviewers most often notice missing.
If the application is not funded, you owe nothing for that work. If it is, the quote stands. See the overview for the four engagement models.
We have a developer already. Can you work with them?
Often the best arrangement, and one of our more common ones. We take the parts that need specialist experience — device integration, store submission, accessibility, the security review — and your developer keeps the domain knowledge and the long-term ownership.
We work in your repository, to your conventions, with code review in both directions. Several of these engagements have ended with us reviewing pull requests occasionally and nothing more, and we count that as a success.
Does an app need to be a medical device?
Usually not, but the question needs a deliberate answer. An app that collects participant-reported data for a study is generally not a device. An app that interprets data and offers a diagnosis, a dose or a treatment decision generally is, and then EU MDR applies.
The boundary is not always obvious, and it moves with a single feature. We assess it during scoping, document the reasoning, and design deliberately to stay on the research side of it.
Where a build genuinely has to be a regulated device, we say so and stop: we do not do MDR technical files, IEC 62304 lifecycles or quality management systems, and a supplier who pretends otherwise costs you a year. We will help you scope what it would take and work alongside a regulatory partner who does that for a living — but the honest answer at that point is that this is a different project.
What happens when the grant ends?
The software is already yours, in your repository, with a runbook. What ends is our involvement, and the handover artefacts exist from the first commit precisely so that the ending is uneventful.
What genuinely does need planning is the maintenance floor: an app in the stores needs a small amount of attention every year to survive operating-system updates. We quote that number up front so it can go in the budget, and we say plainly what happens if nobody pays it — the app stops being installable, usually within about two years.
Can you make it work with our hospital's systems?
Technically, almost always. Organisationally, that depends on your IT department, and we would rather set expectations honestly: getting an integration approved usually takes longer than building it.
So we start the conversation with your IT and security people in week one rather than week nine, arrive with the documents they need, and design a fallback that does not depend on the integration in case the answer is no. Without it, the integration approval becomes a single point of failure outside your control.
How small a job will you take?
Smaller than you might expect. A screening form that works on a shared tablet, a script that reconciles two exports every night, one integration, a fix to something a graduated student left behind — these are days or a couple of weeks, and we quote them as such.
We will also tell you when the job is genuinely too small to be worth a contract, and how to do it yourselves. That has cost us some invoices and earned us most of our best clients.
A build is never standalone.
Describe the thing that does not exist yet.
A paragraph is enough to start: what has to happen, who does it, and when in the protocol. You get back a scope, a fixed price, a date, and an honest note about which parts you could do without us.