one team for firmware, edge-ML, electronics, and regulatory.
One embedded team — firmware, electronics, AI/ML, and regulatory — taking you from concept to FDA clearance, with AI built into the stack, not bolted on. Startup speed, audit-ready rigor.
The update path is pre-authorized: specified model changes ship without a new submission, via a Predetermined Change Control Plan.
FDA 2024 · FDORA 2022We design for both — a locked algorithm, or a continuous-learning model governed inside the loop.
10 guiding principles for Good Machine Learning Practice — FDA, Health Canada & MHRA (2021) — applied across every stage.
Source: FDA AI/ML-Based SaMD Action Plan (2021) · GMLP (FDA · Health Canada · MHRA, 2021) · Predetermined Change Control Plan (FDA final guidance, 2024).
Five vendors means five handoffs — and runway burned in the gaps. We own the device, the intelligence, and the submission as one accountable team.
the usual way: five contracts, five handoffs
the bitcron way: one accountable team
Firmware, electronics, AI/ML, and regulatory in one team. No integration tax. No finger-pointing.
Cross-discipline calls made in one room. Founder pace, with engineering that stays traceable.
Design controls and the DHF grow as you build — never reconstructed in a pre-submission panic.
The regulatory path is designed in from sketch one, so V&V maps clean to your 510(k) or PMA.
Dropping a model into a device is easy. Proving it's safe, reproducible, and cleared to evolve is the work — and we engineer for it from the first dataset.
AI / ML engineering
We own the full AI lifecycle inside the device: data pipelines, model design, on-device deployment, and the V&V evidence that makes it defensible. Regulatory thinking, in the loop from dataset one.
On-device · edge ML
Quantized, latency-bound models that run on the target. Deterministic, and resilient when the network drops.
Edge inferenceSaMD
Standalone clinical software built to IEC 62304, with intended use and risk class designed in from the start.
IMDRF I–IVModel V&V
Reproducible pipelines, dataset provenance, and performance evidence that survives reviewer scrutiny.
TraceableFDA PCCP
Predetermined Change Control Plans that let models improve post-clearance — inside bounds the FDA already agreed to.
Modify by designSignal processing · data pipelines
DSP front ends, sensor fusion, and versioned pipelines: the plumbing that decides whether a model is ever trustworthy. Traceable from raw capture to the prediction it produced.
Source: IMDRF, “Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations.”
Your SaMD category sets the depth of evidence a reviewer expects — and shapes the model, the V&V plan, and the PCCP. We place your device on the grid early, so rigor matches risk.
Not sure where your model lands on the grid? We'll map your SaMD category and the cleanest AI/ML path in a first call.
Talk through the pathway →Hard, regulated, high-stakes systems — where electrons, firmware, and intelligence have to work together safely.
We build inside the standards reviewers and notified bodies expect — so compliance is a byproduct of how we work, not a scramble at the end. The diagrams below are the frameworks we engineer to, drawn to source.
Source: FDA Design Control Guidance for Medical Device Manufacturers (1997) · 21 CFR 820.30, now harmonized under FDA QMSR → ISO 13485:2016 (effective Feb 2, 2026). Verification = outputs meet inputs; validation = device meets user needs.
Source: ISO 14971:2019. Risk = combination of probability of harm and severity of harm. Shading uses ink-intensity with sky/mint (not red/green).
Source: IEC 62304 software life-cycle. Safety classes — A: no injury possible · B: non-serious injury possible · C: death or serious injury possible.
Also engineered to: FDA 510(k) substantial equivalence / PMA · FDA QMSR → ISO 13485:2016 · IEC 60601 · 21 CFR 820.30 design controls → DHF · device Class I–III
Reliability and capability claims have to survive a statistician. We plan sample sizes and capability targets up front, to methods reviewers recognize — so your numbers are defensible, not hopeful.
Source: Success-run (binomial, zero-failure) reliability. “Rule of three”: with 0 failures in n units, the 95% upper bound on the failure rate ≈ 3/n.
| Confidence | Reliability | n (0 fail) |
|---|---|---|
| 95% | 90% | 29 |
| 95% | 95% | 59 |
| 95% | 99% | 299 |
| 90% | 90% | 22 |
Source: success-run theorem. Acceptance sampling: ANSI/ASQ Z1.4 (attributes), Z1.9 (variables).
Source: process capability. Cpk ≥ 1.33 is a common requirement; use Ppk for process performance.
Three stages, with intelligence and the regulatory path weighed at every step — not appended at the end. Built to compress timelines and shrink submission risk.
bitcron assess
01.Pressure-test the concept across the whole stack — where AI earns its place, where it adds risk, your likely SaMD category, and the real regulatory path.
bitcron design
02.Engineer the device, the AI, and the compliance evidence as one system — firmware, electronics, models, and the DHF in lockstep, not colliding before submission.
bitcron validate
03.V&V to ISO/IEC, model V&V, and a complete Design History File — the work, turned into a clean, defensible submission package.
let's talk
Tell us about the device, the intelligence you want inside it, and where you're headed. No pitch deck — just engineers talking about whether we're the team to take it from concept to clearance.