Prende Studio and ULAM LABS wrote this together. It's about what it actually takes to win grant funding as an early-stage MedTech - from how a consortium application gets built and judged, to what a technical delivery partner needs to bring to the table.
Every funding round, strong digital health startups get turned down by Innovate UK, the NIHR, and similar bodies. Founders reading the feedback usually blame the innovation - not novel enough, market too small. Often the real problem sits one layer up, in the consortium itself. Missing expertise, unclear roles between partners - these cost points across feasibility, risk management and team capability, and founders rarely think to look there first. Public funding exists to de-risk real technical and clinical uncertainty - it's not there to subsidise a venture whose delivery team is still unproven. So when assessors go through feasibility, risk management and team capability, what they're really checking is whether the partners line up. Writing the application isn't where the work starts. Putting together the right people and organizations is.
The 4 Core Anchors of a HealthTech Consortium
A consortium that’s built well brings together exactly the expertise needed to cover a digital health project’s main risks on the way to clinical adoption, and each partner has a clear job to do.
- The lead innovator (commercial anchor) - owns the commercial route to market and runs project governance, so there's a credible path from grant-funded prototype to something people actually buy.
- The clinical and evidence lead (an NHS trust, ICB, or specialist clinic) - confirms there's real clinical demand inside live workflows, runs patient and public involvement, and generates the safety and feasibility data.
- The technical delivery partner (specialist software engineering) - builds medical-grade architecture from day one instead of retrofitting it later, with interoperability standards, DTAC and security built in from the start.
- The health economics lead (an academic or HTA partner) - puts together early health-economic evidence, QALYs, cost-per-patient savings, the numbers that tell both assessors and future buyers the intervention actually pays off.
Team credibility and track record
This section isn't really about the innovation. Assessors are asking whether this specific group of organisations will still be shipping working software months from now, and for an early-stage MedTech, that's the hardest thing to prove, because the delivery history they'd point to is usually the very product they're asking the grant to fund.
An established engineering partner closes that gap, and it has to show up in the application itself, not just in the cover letter. Four things matter:
Named people
Most competitions ask for a business plan or product brief - that's where the delivery team belongs, named engineers, their CVs, who's accountable for which piece of work.
Comparable systems already running
Not a claim that you can build healthcare software - a system in the same class, with numbers an assessor can actually check.
Evidence, not just promises
Before the bid goes in, a technical partner can produce a reference architecture, an integration plan naming the actual systems and standards involved, and a prototype moving real data.
What happens when the grant runs out
Assessors have seen prototypes die the day the funded developer leaves. A stable team heads that question off before anyone asks it.
If the applicant has no delivery bench of its own, the partner effectively is the team, and the partner's track record becomes the bid's track record.
Here's what that looks like on our side, as the technical delivery partner: Relevance beats scale here. We can point to a hospital operations platform now running in over 200 hospitals after five years, it went from 10 sites to 70 in under a year without any downtime, and to a DSPT-compliant NHS patient pathway platform we delivered with one engineer and one QA in two months.
The first shows a product that survived past the pilot stage. The second shows a small team hitting a fixed scope on a fixed clock, which is exactly what assessors are being asked to believe will happen on the applicant's own project. On continuity, the numbers are about us as a company: we've been building since 2017, our delivery team is 94% mid-to-senior, and average tenure is four and a half years.
These feasibility artifacts usually come out of a short discovery engagement run before the bid is even written, and that same engagement is where the milestone plan comes from. That order matters, because the milestone plan later becomes the budget. Every competition accepts different supporting material, so a technical partner needs to be able to shape these artifacts to whatever a specific call asks for.
A technical partner named on the cover page but missing from the work packages raises an obvious question: what are they actually contributing? If a partner is in the consortium, they should own deliverables.
Bridging Clinical Ambition and Technical Execution
The friction in early-stage bids usually shows up right at the bridge between clinical ideas and actual software. Bringing an experienced technical partner into the consortium early can make the application much more credible:
-
Realistic milestones: speculative timelines are replaced with defensible, milestone-driven development sprints
-
Embedded regulatory alignment: Software as a Medical Device (SaMD) considerations and information governance are built directly into the foundational software design
-
Post-grant viability: this gives assessors a clearer basis for judging whether the platform could move beyond the grant-funded prototype towards real-world deployment
The Technical Risk Checklist
Risk sections fail for the same reason every time: generic risks paired with generic mitigations. What actually scores is a short list of named risks where each mitigation traces back to a specific work package, not just a good intention.
EHR and GP system access
Approval and pairing timelines for NHS Login, PDS, GP Connect, IM1, or a trust's EPR - these sit with the vendor, not with you. Build against the FHIR interface using synthetic data from sprint one, so when live integration finally happens, it's a swap, not a rewrite.
Data quality and availability
Clinical partner data is almost never in the state the project assumes it'll be in. Put a readiness assessment in the first work package, with a real go/no-go decision before the build scales up.
Interoperability standards
FHIR UK Core, HL7 v2, DICOM for imaging. A custom internal data model might get the grant over the line and still leave you with a product nobody downstream can actually adopt.
Information governance and security
DSPT-aligned architecture, role-based access, audit logging, encryption, UK data residency, a DPIA, and a stated lawful basis. If NHS deployment is the goal, the DTAC technical sections are a decent checklist to build against.
Regulatory pathway
Work out early whether what you're building counts as Software as a Medical Device. If it does, DCB0129, ISO 14971 and IEC 62304 traceability change both how it's built and what it costs, and finding that out late is a budget problem, not a paperwork problem.
IP and infrastructure after the grant
The section everyone skips. Who owns the foreground IP, what licence the clinical partner keeps, and who holds the repository, the cloud accounts and the credentials on day one after funding ends.
Documented compliance is a credibility signal on its own. Assessors can tell the difference between a consortium that treats governance as part of the build and one that treats it as paperwork to bolt on after the money's already spent.
How Applications Are Evaluated: The 3 Core Assessment Pillars
Although the terminology and structure vary between competitions, many Innovate UK and NIHR assessments consider these three broad areas:
Need and Market
- Is there verifiable clinical demand?
- Is the addressable market backed by genuine care pathway bottlenecks rather than top-down assumptions?
Approach & Work Packages
- Are the technical and clinical work streams interlocked?
- Does each sprint produce a verifiable deliverable?
Risk Management & Delivery Capability
- Can the consortium actually execute, and keep executing, when an unexpected technical or regulatory problem shows up?
Work Packages and Budgeting
Software development should never be a single line in the budget. It gives an assessor nothing to check against, and it's one of the easiest ways to lose points on an application that's otherwise solid. Break the build into milestones instead, and end each one with something a reviewer can actually open.
A structure that works for most digital health builds:
- Discovery and regulatory mapping - user flows, a prioritised backlog, and the compliance constraints written down before the architecture gets locked in.
- Architecture and information governance - reference architecture, data flow map, DPIA, hosting decision.
- Core build - two-week sprints, each one ending in working software with a sign-off, not just a status update.
- Integration - kept as its own package, because the risk here is external and the timeline isn't the consortium's to control.
- Security and clinical safety evidence - test report, remediation log, requirement-to-test traceability.
- Deployment and handover - runbook, plus the access handover described above.
Two things make a budget defensible. First, cost built from roles - person-months against named roles at a stated day rate, so assessors can weigh effort against deliverable. Second, milestones that can actually fail: if a work package can't fail, it isn't really a milestone. Write the go/no-go decisions down - data readiness at the end of WP1, for instance.
Treat compliance as engineering work, not paperwork to write up later. Audit logging, role-based access, traceability - these take real engineering time, and the applications that push them to the end are the ones that run out of budget in the final quarter.
The budget should also show what happens once the funding stops, even where those costs sit outside the grant itself - monitoring, updates, system upkeep, priced as a standing fee plus some room for ad-hoc work. When assessors are checking for post-grant viability, they want to see that someone has already worked out who runs the product once the money's gone.
Closing The applications that score well share one thing: strict delivery discipline. Work packages need clear milestones tied to technical benchmarks and clinical recruitment targets, before unlocking subsequent project stages.
Non-dilutive capital should accelerate market readiness, not bury a team in paperwork. Securing funding requires proving to assessors that your consortium has the clinical credibility, technical soundness, and governance required to build a product ready for adoption once the grant period ends.
Planning a bid?
Prende Studio is an independent strategy and research practice working with founders, leadership teams and research organisations navigating growth, commercialisation and complex partnerships. Founded by strategy and innovation consultant Jona Shehu, it combines research, strategic advisory, partnership development and communications to help organisations clarify their direction and move ideas into practice. Its work includes grant development and consortium coordination as part of this broader support. Based in London, Prende works internationally. prendestudio.co.uk
Frequently asked questions
When should a technical partner join the consortium?
Before the application is written. The feasibility evidence - reference architecture, integration plan, a prototype moving real data - comes out of a discovery workshops, and that same engagement produces the milestone plan that later becomes the budget. Bring a partner in after the bid is drafted, and you end up retrofitting both.
We already have developers in-house. Does that change anything?
It changes what you need the partner for. If you already have a delivery team, the gap is usually evidence, not capacity - the reference architecture, integration plan and risk register still need to exist in a form an assessor can read. If you don't have an in-house team, the partner is the team, full stop.
How detailed does the budget need to be?
Detailed enough that every line traces back to a deliverable: person-months against named roles at a stated day rate, milestones that can genuinely fail, and a written go/no-go decision at the points where the project could actually stall.
Can a technical delivery partner based outside the UK join a UK consortium?
Yes, although eligibility rules vary significantly by funding body. Most public grant frameworks require the lead entity to be domestic and expect the primary economic benefit and project spend to remain within the funding jurisdiction. An international technical delivery partner typically joins in one of two ways: either as official consortium members (under bilateral or global calls such as Eureka or Horizon Europe) or as specialist subcontractor delivering dedicated work packages. Under Innovate UK rules, for example, non-UK software partners frequently operate as subcontractors. The key to scoring well is clearly demonstrating the partner's distinct value-add, such as specialised domain expertise, a proven delivery track record in health systems, and cost efficiency, while ensuring that local regulatory requirements, data residency, and clinical governance standards (such as DSPT and DTAC in the UK) are rigorously satisfied.
Who owns what is built?
Settle this before you submit, not after: who owns the foreground IP, what background IP each partner brings in, what licence the clinical partner keeps, and who holds the repository, the cloud accounts and the credentials once funding ends.
