When someone gets in touch with a device idea, one of the first things they usually want to know is what the path from idea to a product on the market actually looks like. It’s a fair question, because from the outside the process can seem fairly opaque, and there’s quite a bit of conflicting information online (much of it written for the US market, which doesn’t map neatly onto the UK). My view is that it breaks down into five phases, and that’s broadly how we run projects at MDIN. In practice the phases overlap more than any tidy diagram suggests, and the documentation runs alongside the design work rather than being a separate job bolted on at the end, but as a way of understanding where you are and what comes next, five phases works well.
Phase 1: concept and feasibility
This is where the idea gets tested against reality before serious money is spent. The questions are simple enough to state: what is the device for, who uses it, what does it actually need to do, what’s already on the market, and is there an obvious technical or regulatory reason it won’t work. In the UK that last point means working out the likely classification under the Medical Devices Regulations 2002 (as amended) and the probable route to UKCA or CE marking, because the classification drives how much evidence you’ll need later, and it’s far better to know that before the design is fixed.
On the technical side, I’d always push to get something physical made early, even if it’s crude, because a part you can hold answers questions a CAD model can’t. When HelloCath came to us we went from first conversations to several rounds of silicone prototypes, manufacturable drawings and a mapped regulatory pathway in a few weeks, and that’s what a good feasibility phase should give you: a clear answer one way or the other, or a short list of what still has to be proven. We run these as structured concept feasibility studies, and the HelloCath case study shows what the output looks like.
Phase 2: design and development
Once the concept holds up, the work shifts to turning it into a device that can actually be made. The design inputs get written down properly (what the device must do, the standards it needs to meet, the use environment, the users), and the design then develops through iterations of CAD, prototype builds and informal testing. I’ve written before about the difference between a proof of concept and a prototype, and this phase is where that distinction matters most, because knowing which build you’re doing stops you polishing parts that only exist to answer a question.
Because we prototype in-house at our workshop near Bristol, with resin printers, silicone moulding and a lathe on site, iterations tend to be quick, and the speed of the loop between “idea” and “part on the bench” is what decides how good the final design is. Two things need to start in this phase rather than later: risk management under ISO 14971, which should grow with the design rather than be written retrospectively, and some honest thought about manufacture, because a design that can only be made by the prototyping process that built it will cause pain in phase 5. Our design and development page covers how we structure this work.
Phase 3: verification and validation
Verification is testing the device against the specification you wrote in phase 2, and it’s mostly a bench exercise: forces, dimensions, cycle counts, performance under worst-case conditions, carried out to written protocols with recorded results. Validation asks a different question, which is whether the device actually works for the intended users in the intended use, and depending on the device that can mean simulated use studies, usability work or clinical evidence.
This is the phase people most often underestimate, in terms of both time and kit. A lot of device testing needs fixtures and rigs that don’t exist off the shelf, so we design and build bespoke test rigs in-house and run force and displacement testing on our own calibrated test equipment, which keeps the loop between a test failure and a design change short. It also means early informal versions of the formal tests can run during phase 2, so by the time the written protocols come round there are rarely surprises in the results. The useful habit here is writing every protocol against a numbered design input, so that each report closes a requirement and drops straight into the technical documentation. Testing that doesn’t trace back to a requirement doesn’t move you towards market.
Phase 4: the technical file and UKCA or CE marking
If the documentation has been built alongside the work, this phase is largely assembly rather than creation: the risk file, the design and test records, the clinical evaluation, labelling and instructions for use all come together into the technical file. I’ve covered what actually goes into a technical file separately, and the short version is that the file is the evidence that the device is safe and performs as intended, whatever its class.
The route then depends on classification. Most Class I devices in the UK (the non-sterile, non-measuring ones) can be self-declared, with MHRA registration, though the technical file still has to exist in full. Higher classes need an approved body for UKCA or a notified body for CE, and the choice between the two routes is worth making deliberately, because CE marked devices remain accepted on the GB market until 30 June 2028 for directive-certified devices and 30 June 2030 for devices certified under the EU MDR, and the MHRA consulted earlier this year on recognising CE marked devices indefinitely (the consultation closed in April and no outcome has been published as I write this). I’ve set out how I’d approach that decision in UKCA vs CE marking in 2026. Our role at MDIN is designing, testing and preparing the device and its documentation so it’s ready for whichever route is chosen.
Phase 5: manufacture and post-market
Design transfer is the point where the design stops being something we build on the bench and becomes a pack a manufacturer can work from, meaning drawings with tolerances a supplier can actually hold, inspection criteria, assembly instructions and agreed acceptance testing. It goes far more smoothly when manufacture was considered back in phase 2, which is why I keep banging on about it there.
The work doesn’t stop at launch. The GB post-market surveillance requirements were strengthened in June 2025, so manufacturers need a documented PMS plan, active collection of production and field data, and defined timescales for reporting serious incidents to the MHRA. Complaints and field data feed back into the risk file and, where needed, into design changes, which is really the five phases looping round again in miniature.
Where to start
The phases overlap, and that’s fine. Building the documentation while the design work happens is cheaper and produces a better file than doing either in isolation. If you’ve got a device at any of these stages, whether it’s a sketch or a stalled technical file, I’d be happy to have a call and talk through where you are and what the next sensible step would be. There’s no charge for that first conversation, and you can book a free call here.
Frequently asked questions
It depends mostly on the classification and the novelty of the device. A simple Class I device with a clear predicate can move through the phases in months, while an implantable or drug-device combination product is a multi-year programme, mainly because of the evidence needed in phases 3 and 4. The feasibility phase is the cheapest place to find out which you’re dealing with.
Not to start, no. Early feasibility and design work can happen before a certified QMS is in place, but the design work should follow design controls from phase 2 onwards so the records exist, and depending on your class and route you’ll need an appropriate QMS in place before the device goes to market.
From phase 1, in my view. The file is mostly made of records the project generates anyway (requirements, risk analysis, test reports), so capturing them properly as you go costs little, whereas reconstructing them at phase 4 is slow and expensive.
The development work is essentially the same, since both routes rest on the same kind of technical documentation and evidence. What differs is the conformity assessment route at phase 4 and some of the registration and post-market details, which is why it pays to pick your route early.