HealthTech & SportsTech · how we work
Movement and body signals, measured by a phone or wearable, on the device.
We build and fix perception models for product companies without an in-house ML team: pose and movement analysis, test strips and vitals read by a camera, signals from body-worn sensors. Trained on your recordings, running on your users' hardware, with accuracy measured before and after. You keep the code and the IP.
Can it be measured?
Will a phone camera or a sensor even catch this?
Vendor or SDK failed
Months in, the model still does not work.
Raising / pause
We are raising. Development has to wait.
Launch
The feature has to work in the app, on the phone.
Accuracy complaints
Reviews say it counts wrong.
Expansion
A new sport, a new test, a version for clinics.
- 200+projects delivered
- 300+scientific publications
- 10+years on vision, audio and edge
- PhDlevel engineering team
- 15→120FPS after optimisation, Fanaty
- 93%+accuracy on a phone camera, Pardigm
In short
What we build, and what it costs you to find out
A camera or sensor feature that works in the lab and fails on users is the usual starting point: fast motion, poor light, one platform, a cloud bill that grows with every user, or a measurement a person still checks by hand. We retrain or build the model on your recordings, move it onto the device and ship the second platform.
The work is a ladder of six separate engagements. The first is free and takes a day. The second is a fixed-price two-week research that ends with a written go or no-go and a priced plan for the proof of concept. Every later step is priced from the results of the one before it. You can stop after any step and keep everything produced so far.
How we work
Six steps. Stop after any of them.
Each step is a separate engagement with a fixed estimate, its own deliverable and its own acceptance test. A pause between steps while you raise or ship is normal.
Send what you have: a spec, a few recordings, the platforms you ship on. Within a day you get our verdict: whether the feature can be measured, and what it would take.
You get
- feasibility verdict in writing
- the risks we see
- the recommended next step
Done when
You know whether to book the research, go straight to a PoC, or stop.
Proof
Two or three candidate models run on your recordings, with accuracy measured rather than estimated. A technical report, an architecture outline and a PoC roadmap with a fixed price.
You get
- numbers on your own recordings
- a catalogue of where it breaks
- cloud or device, decided with evidence
- PoC roadmap and price
Done when
A written go or no-go, with a priced plan for the proof of concept.
Proof
A working demo on your data, with accuracy measured before and after. Converted and timed on an average phone where on-device is the target.
You get
- a model trained on your data
- a working demo your pilots can use
- accuracy before and after
- code and trained weights
Done when
Accuracy on your test set, scored before and after.
Proof
Your first app version in users' hands: a capture flow with filming guidance, the on-device model from the PoC, results and history screens, a minimal backend, an internal or TestFlight build.
You get
- capture flow with filming guidance
- on-device model, wired to the screens
- minimal backend for upload and analytics
- TestFlight or internal build, code and IP yours
Done when
PoC accuracy holds on pilot users' recordings; the build runs on the agreed devices.
Proof
Your model in your next release, on both platforms: retrained on production data, integrated alongside your developers, with release engineering and a knowledge transfer into your team.
You get
- retrained model on iOS and Android
- integration with your team, in your repositories
- backend, analytics and release engineering
- handover: documentation and knowledge transfer
Done when
Accuracy before and after, and speed on an average phone, both written into the scope.
Proof
Your model keeps its accuracy as users, phones and OS versions change: retraining on new failure cases, fixes after OS and device updates, a one-page accuracy report and priority response.
You get
- retraining on production failure cases
- fixes after OS and device updates
- a monthly accuracy report against the baseline
- priority response when the model misbehaves
Done when
Monthly accuracy at or above the release baseline.
Proof
Where the alternatives stop
What you are comparing us with
A CTO with a camera feature has four other options. Here is where each one works and where it stops.
- Loses fast motion and objects it was never trained on
- The per-user fee grows with your audience
- You cannot retrain or fix the model
- Generic: trained on nobody's scenes in particular
- False alarms and misses you cannot tune out
- Months of hiring before any work starts
- One person becomes the single point of failure
- Experience mostly in text and LLM work
- Little work on sensors or on models that run on a device
- Reviews and churn eat the growth
- A competitor ships a better version
Questions founders ask
Before the first message
You do. All code, trained weights and IP are handed over at the end of each step. We keep no licence on your product.
Yes. Each step ends with a handover, so a pause while you raise or ship costs nothing. The next step starts from what the previous one produced.
No. The ladder is designed for product companies with fewer than two ML people. Your lead engineer or CTO is the counterpart. They get the code, the training pipeline and a written explanation of every decision, so the model can live in your team after handover.
Not always. The two-week research answers the cloud versus edge question with numbers: accuracy after conversion to Core ML or LiteRT, speed on an average phone, and cost per user in the cloud. Where a device model loses too much accuracy, we say so and propose a hybrid.
You do. Your quality system (ISO 13485, IEC 62304, FDA, EU MDR) stays with you, and we work inside it: documentation, requirement tracing and patient data protection follow your procedures. We do not make or certify medical claims.
Recordings. For the assessment, a description of the feature and a few sample clips or sensor logs. For the technical research, a set of your real recordings, including the bad ones: fast motion, poor light, cheap Android cameras. The failures teach us more than the clean clips.
Each step has a fixed estimate agreed before it starts. The assessment is free, the technical research is a fixed price, and the research itself produces the fixed price and timeline for the proof of concept. Later steps are priced from the results of the previous one.
You get the reasons in writing: which conditions break the models, what accuracy ceiling we hit and what would have to change. Some of the most useful outcomes have been a 'not yet' delivered before a build was funded.
Free assessment
Send what you have. Get our verdict in a day.
A spec, a few recordings the way your users would film them, and the platforms you ship on. An engineer who has shipped camera models on phones reads it, not a salesperson.
- 1You send a spec and a few recordings
A paragraph on the feature, a link to clips or sensor logs, the platforms. NDA first if you need one.
- 2An engineer reviews it
The CTO or a domain expert goes through the measurement, the conditions and the platforms.
- 3You get the verdict within a day
Whether the feature can be measured, the risks we see, and the recommended next step, in writing.