Six markets
we know cold.
We would rather be genuinely useful in a handful of sectors than plausible in twenty. In these, we already know the constraints, the standards and the specific ways programmes go wrong.
Sector 01
MedTech &
diagnostics
Devices and instruments where the engineering is hard and the evidence bar is harder, and where the two have to be planned together from the beginning.
What we build here
- Point-of-care and near-patient instruments
- Imaging and image-analysis systems
- Wearable and implantable device software
- Drug delivery and injection devices
- Surgical instruments and capital equipment
- Device companion and configuration apps
- Instrument control software and firmware
- Service, diagnostics and fleet telemetry
Where programmes usually stall
- Human factors treated as a test at the end rather than a design input at the start
- A regulatory pathway chosen after the architecture has hardened around a different one
- Design transfer beginning before the design is genuinely stable
- Verification protocols written against requirements that were never testable
Product research · Product design · Product engineering · Applied AI · Digital health
Standards
Sector 02
Digital health
& therapeutics
Software that makes a clinical claim. The product problem and the evidence problem are the same problem, and treating them separately is the most common way to lose a year.
What we build here
- Prescription digital therapeutics
- Software as a Medical Device (SaMD)
- Remote patient monitoring platforms
- Clinical decision support tools
- Care-team dashboards and triage tooling
- Patient engagement and adherence systems
- EHR-integrated workflows (SMART on FHIR)
- Digital front doors and screening pathways
Where programmes usually stall
- An intended-use statement broad enough to sound exciting and impossible to substantiate
- Engagement mechanics designed for consumer retention, then failing in a clinical population
- No reimbursement story, so a validated product has no route to a buyer
- Security and privacy work started after the data model was fixed
Digital health · Product research · Product design · Applied AI · Clinical evidence
Standards
Sector 03
Life sciences &
clinical research
Sponsors, CROs and sites running studies that are more decentralised, more instrumented and more data-heavy every year, usually on tooling that was not designed for any of that.
What we build here
- Decentralised and hybrid trial platforms
- eConsent, eCOA and ePRO systems
- Participant apps and adherence tooling
- Wearable and sensor endpoint pipelines
- Digital biomarker validation infrastructure
- Site-facing tools and burden reduction
- EDC, CTMS and eSource integrations
- Registry and real-world evidence platforms
Where programmes usually stall
- Device logistics and provisioning underestimated at protocol design
- Endpoints chosen for what the sensor reports rather than what is clinically meaningful
- Validation planned as a documentation exercise after the software is written
- Site burden that quietly caps recruitment regardless of participant demand
Clinical evidence · Digital health · Product research · Product engineering · Applied AI
Standards
Sector 04
Industrial &
laboratory automation
Systems judged on uptime, throughput and cost per unit, where an elegant solution that needs supervision is worth less than a plain one that does not.
What we build here
- Robotic cells and sample-handling systems
- Automated inspection and vision QC
- Benchtop instruments turned into products
- Liquid handling and consumable automation
- Machine control software and HMI
- Predictive maintenance and fleet telemetry
- Digital twins and throughput simulation
- Operator training and remote support tools
Where programmes usually stall
- Consumable and material variance discovered after the mechanism is committed
- No designed recovery path, so every fault needs a specialist
- Throughput modelled on nominal cycles rather than real ones with faults included
- Serviceability treated as an afterthought, then dominating cost of ownership
Robotics & autonomy · Product engineering · Product design · Applied AI · Spatial computing
Standards
Sector 05
Training &
simulation
Immersive training earns its budget when it shortens time to competence and produces a record someone will accept. Otherwise it is an expensive demo that people do once.
What we build here
- Surgical and procedural VR simulators
- Device and instrument training modules
- Industrial safety and maintenance training
- Assessment models and competence scoring
- Instructor tooling and cohort analytics
- AR guidance for field and service teams
- Haptic and physical-model integration
- LMS integration and fleet management
Where programmes usually stall
- Fidelity pursued everywhere instead of where it changes the learning outcome
- No assessment model, so the only reportable metric is completion
- Session length designed without testing comfort across a full training block
- Headset logistics and hygiene ignored until rollout
Spatial computing & XR · Product research · Product design · Applied AI
Platforms
Sector 06
Consumer health
& wellness
Products living exactly on the regulated edge, where a wellness claim and a medical claim are separated by one sentence of marketing copy.
What we build here
- Connected wearables and home devices
- Sleep, cardiac and metabolic tracking
- Companion apps and coaching experiences
- On-device signal processing and ML
- Subscription and content platforms
- Data and insight engines
- Accessibility and inclusive product design
- Claim substantiation and study support
Where programmes usually stall
- Marketing claims drifting into medical-device territory without anyone deciding to
- Sensor accuracy validated in a lab and never in the population that buys it
- Retention mechanics that peak at week two and fall off a cliff
- A hardware BOM locked before the software knows what it needs
Product design · Product engineering · Applied AI · Digital health · Product research
Considerations
Outside these sectors
We will tell you if
we're the wrong firm.
The technical practices travel further than the sector list suggests. We have taken the same AI, robotics and product engineering work into adjacent markets where the constraints rhyme.
But if your programme needs deep domain knowledge we do not have, the honest answer is worth more to you than the engagement is to us. Ask, and we will say so on the first call.
Ask us directlyNext step
Working in one
of these markets?
Tell us where you are in the programme and what is worrying you. We will tell you what we would do about it, before there is any question of an engagement.