Learn the lifecycle
before you live it.
The deep-tech product lifecycle — with quality and regulatory compliance built in — taught in plain language for startup founders and fresh graduates. No jargon walls, no gatekeeping, no invoice.
01 — WHY THIS EXISTS
Nobody warns you that the document you skip in month two becomes the audit finding in year two. We teach the lifecycle the way we practice it — so the lesson costs you fifteen minutes now instead of six months later.
02 — TRACK 01: FROM IDEA TO APPROVED PRODUCT
Five lessons. The whole arc.
Read in order the first time — each lesson stands on the one before it.
L/01 Deep-tech is different Mission-critical products fail differently — so they're built differently. +
A consumer app can ship with bugs and patch them on Tuesday. A patient monitor, a drone payload or a production-line controller cannot — when these products fail, someone is harmed, a mission is lost, or a factory stops. The cost of failure, not the technology, is what makes a product "deep-tech": it sets the rules for how you must build.
Almost every mission-critical product shares one anatomy. It senses a signal — physical, physiological or biological — conditions it, digitizes it, computes on it, connects it, and supports a decision. Learn that chain and you can read any instrument like a diagram.
Two consequences follow. First, every engineering discipline along the chain has to agree with the others — which is why systems engineering, not any single specialty, decides whether the product works. Second, someone outside your company — a regulator, an auditor, a procurement officer — must be convinced before anyone is allowed to rely on it. That gatekeeper is part of your product plan, not an obstacle at the end of it.
Remember
- The cost of failure sets the rules — budget and schedule must respect it.
- The signal chain is your product's anatomy: sense → condition → digitize → compute → connect → decide.
- An external gatekeeper is part of the plan from day one.
L/02 Intended use comes first The most expensive sentence in your company describes what your product is for. Write it before you build. +
Founders start with a demo. Regulators start with a sentence: what is this product intended to do, for whom, in what setting? That sentence — the intended use — determines your device classification, and classification determines everything downstream: which approvals you need, what evidence you must produce, how long it takes, what it costs.
The same hardware can be a wellness gadget or a regulated diagnostic depending on the words you choose. "Tracks your sleep" and "detects sleep apnea" are different companies with different futures — one ships next quarter, the other needs clinical evidence. Neither choice is wrong; making it accidentally is.
So the order of work is: write the intended use, name the user and the environment, derive the requirements — and only then design. That package is the systems definition: the scope everyone signs before anyone draws.
Remember
- Intended use determines class; class determines evidence, cost and timeline.
- The same hardware with different claims is a different product.
- Requirements before CAD — always.
L/03 Design controls aren't paperwork Design controls are just engineering with receipts. +
Design controls have a fearsome reputation and a simple core: write down what the product must do (inputs), what you designed (outputs), and the evidence that the two match. Verification asks "did we build it right?" — tests against the requirements. Validation asks "did we build the right thing?" — evidence that it works for the real user, in the real environment. Confusing the two is the most common audit finding in young companies.
The trick that separates calm companies from panicked ones: document while you design, not after. Captured as you go, the design history practically writes itself; reconstructed a year later, it costs ten times more and convinces no one. Your future auditor reads your past discipline.
And prototype early — a looks-like model and a works-like rig kill more risk in a month than a quarter of meetings. Every risk you retire before freezing the design is documentation you won't have to defend twice.
Remember
- Verification = built it right. Validation = built the right thing.
- Document while designing — retrofitting costs ten times more.
- Prototype to surface risk early, not to impress investors.
L/04 Quality systems, minus the fear A QMS is how your company behaves when nobody's watching — the standard just writes it down. +
A quality management system is not a binder; it's your company's habits, written down so they survive growth and turnover. ISO 13485:2016 is the version of those habits that medical device regulators worldwide recognize — build your system on it once, and it travels with you from CDSCO to FDA to Health Canada and across IMDRF-aligned markets.
Running through everything is risk management (ISO 14971): a living file of what could go wrong, how badly, and what you did about it. It starts on day one and never closes — every design choice, every change, every complaint feeds it.
The startup mistake comes in two flavors: building the QMS too late (retrofitting pain, lesson three) or too heavy (a fifty-procedure system for a five-person team that nobody follows — and a system nobody follows is an audit finding, not an asset). Right-size it to your stage, then let it grow with you.
Remember
- ISO 13485:2016 is the backbone that travels across markets.
- The risk file is living — it opens on day one and never closes.
- Right-size the QMS: too heavy fails the same audit as too late.
L/05 Approval is a milestone, not the finish line The product you launch is the youngest version of itself — plan for its whole life. +
The most underestimated step in the lifecycle is design transfer: turning a validated design into something a factory can build a thousand times. It's a project with its own documents, training, fixtures and supervised first runs — not a meeting where engineering hands manufacturing a folder.
Then the product goes out and starts talking back. Post-market surveillance — complaints, field data, trend reports — is a system you run, not a mailbox you check. Regulators expect you to listen, and your next product is hiding in what you hear.
Finally: every change to the product re-asks the regulatory question. A new supplier, a firmware update, a cheaper sensor — each one runs through change control, or your approval quietly stops describing the product you actually ship. Companies that plan for the whole life ship better products and sleep better doing it.
Remember
- Design transfer is a project, not a meeting.
- Post-market surveillance is a system you run, not a mailbox you check.
- Every change re-asks the regulatory question — change control keeps your approval true.
Finished the track? You now know more about the lifecycle than most teams do at their first audit. When your product is real enough to have questions of its own — that's what the fifteen minutes are for.
Book 15 minutes→03 — IN THE PIPELINE
More tracks are being written.
Regulatory Pathways
CDSCO, US FDA and the harmonized world — choosing and walking your route to market.
QMS for Startups
Building a right-sized ISO 13485 system — what five people actually need.
The Signal Chain, Deeply
Sensors to decisions for engineers — the instrumentation track.
New lessons land on the Substack first. Subscribe and they find you — no algorithm required.
Subscribe on Substack →LEARNING FOR A REAL PRODUCT?
Bring it.BOOK 15 MINUTES — OR WRITE TO INFO@UNPLEX.TECH