The First-Time 510(k) Tax 🔗
My first 510(k) cost my team over a year of avoidable work. Not because the device was complex. Not because FDA was unreasonable. Because we did not know what "enough" looked like.
We traced everything to everything. We wrote 70-page software development plans. We built automated verification suites for requirements that labeling could have satisfied. Our risk management plan was 70 pages when 7 would have cleared. We worked nights and weekends producing documentation nobody at FDA asked for and nobody at FDA cared about.
That is the first-time 510(k) tax. Most teams pay it. Most teams do not realize they are paying it until they are 12 months deep.
The honest version: if my first team had worked with an experienced regulatory partner from day one, we would have saved a year of engineering time, six figures of burned runway, and the late-stage burnout that loses you key people right before submission.
This article walks through the actual artifacts of a cleared AI/ML SaMD 510(k) for Body Check CT Cardiomegaly (K232613). The point is not to hand you templates to copy. The point is to show you, section by section, where first-time teams overbuild, where they panic, and where an experienced team would have cut the work in half before you started.
Are you allowed to disclose that? 🔗
Our client, Body Check, has granted Innolitics permission to share snippets of the FDA submission so we can show you exactly where the pain shows up. Innolitics takes confidentiality very seriously and will never share such information without written permission.
eSTAR Application 🔗
First-time pain: spending weeks chasing every “?” tooltip, over-declaring conformity, and ordering documents nobody asked for. We were ready to pay thousands of dollars for a DICOM conformance statement before we realized FDA did not require it. Your customers may still want one, but you can address that when it actually is a problem. You will not have customers without clearance first.
What experience buys you: someone who knows which prompts matter, which are optional, and which create more risk than they avoid.
Product Development Plan (Software Development Environment Description) 🔗
First-time pain: this is the document where teams hide the most fluff. Mine ballooned to 70 pages of process theater. None of it improved the device. All of it had to be maintained for the life of the product.
What experience buys you: the spine of a Product Development Plan FDA actually wants. Scope, references, responsibilities, phases, deliverables, traceability, configuration management, verification. Done. No padding.
Risk Management Plan 🔗
First-time pain: confusing “thorough” with “long”. Teams write 70-page plans because they cannot tell which sections FDA actually reads. The first time I prepared a 510(k), this single mistake cost my team 4 months of full-time engineering. Even knowing an FDA-approved Risk Management Plan can be 7 pages would have saved a month.
What experience buys you: a 7-page plan that cleared with no FDA pushback. Same methodology (MAUDE reviews, FMEAs, usability risks, 5-level likelihood and severity, acceptability matrix). None of the bloat.
System and Software Architecture Diagram 🔗
First-time pain: trying to draw the whole product. Every microservice, every helper, every dependency. The diagram becomes unreadable and unmaintainable.
What experience buys you: one diagram scoped to the device. Software items, layers, data flow, interfaces. Nothing else.
Due to confidentiality agreements, we cannot share the actual diagram. Check the related article for the principles.
Software Requirements Specification 🔗
First-time pain: writing a requirement for every line of code. Teams overspecify, then watch verification balloon to match.
What experience buys you: requirements scoped to the risk and the predicate. Functional, performance, interface, security, regulatory. Five categories. Move on.
Due to confidentiality agreements, we cannot share the actual document. Related reading:
Risk Assessment 🔗
First-time pain: 52 pages of hazards because the team cannot tell which ones FDA actually expects to see, so they pad out of fear.
What experience buys you: hazards mapped to predicate, intended use, training data, and known failure modes. Length is a side effect of the analysis, not a goal.
Related reading:
User Manual 🔗
First-time pain: not knowing that labeling is a valid mitigation. We wrote a complex test script to simulate contraindicated scenarios when a clear list of contraindications in the user manual would have satisfied the same requirement. That single misunderstanding cost my team a cumulative 8 months over 5 years of writing and maintaining tests that should have been a checkbox.
What experience buys you: a regulatory partner who tells you, before you start coding, which requirements close with a sentence on a page and which require a verification script.
Risk Management Report 🔗
First-time pain: not knowing where the Plan ends and the Report begins. Teams duplicate content across both and fight to keep them in sync for years.
What experience buys you: a clean Report that confirms residual risk is acceptable, points to post-market monitoring, and references the Plan instead of restating it.
Substantial Equivalence Discussion 🔗
First-time pain: a comparison table that loses on technological characteristics because the team did not understand which differences trigger which FDA questions. Then the team scrambles to add testing six months in.
What experience buys you: a substantial equivalence narrative that anticipates the FDA reviewer's read, structured around intended use, target population, technological characteristics, and performance testing.
Cover Letter 🔗
First-time pain: filling this form out wrong can make your entire submission public. Most first-time teams have no idea. They find out the hard way.
What experience buys you: not finding out the hard way.
Software Label 🔗
First-time pain: duplicating user manual content into the label, then updating one without the other, then explaining the inconsistency in an AINN response.
What experience buys you: a one-page label that points to a single source of truth.
Device Description 🔗
First-time pain: writing this five times across five documents, then trying to keep them in sync.
What experience buys you: one source, referenced everywhere. The same content shows up cleanly in the 510(k) summary, Software Description, and Risk Assessment without divergence.
Software Description 🔗
First-time pain: confusing this with the architecture diagram, the Software Requirements Specification, and the Device Description. Teams write the same content four ways and watch the contradictions surface during AINN.
What experience buys you: clarity on which document carries which payload. Software Operation covers operators, intended patient population, data analysis methodology, and a high-level data flow. Machine Learning Models covers slice localizer, heart segmentation, and inner chest segmentation, including architecture, training parameters, and hyperparameters. Software Inputs and Outputs covers I/O format, interoperability, performance testing, intended audience, and network or cloud storage. Each goes here. Not anywhere else.
Verification Plan and Report 🔗
First-time pain: building automated test infrastructure for requirements labeling could verify. Teams write thousands of lines of test code, then maintain them for the life of the product.
What experience buys you: a verification matrix that maps risk to test type. Some activities are scripts. Some are inspections. Some are sentences in the user manual. Each carries the right level of rigor and no more.
Software Version History 🔗
First-time pain: assuming FDA expects a long history before you can submit.
What experience buys you: a one-pager. One version. We proved it can be done.
SOUP and OTS Report 🔗
First-time pain: documenting every dependency in exhaustive detail. Hundreds of pages of churn that nobody at FDA reads.
What experience buys you: 7 pages.
Traceability Analysis 🔗
First-time pain: tracing everything to everything. Hazard to risk to control to requirement to verification, in every permutation. The matrix does not fit on landscape 11x17, and the team spends two weeks fighting the format. Mine did.
What experience buys you: a 5-page traceability that cleared with no FDA pushback.
Unresolved Software Anomalies 🔗
First-time pain: believing software must be defect-free before submission. So the team holds the submission for a defect labeling could have handled.
What experience buys you: a known defect, a labeling-based mitigation, and a cleared device.
Clinical Performance Assessment Protocol 🔗
First-time pain: designing endpoints the device cannot pass, or that FDA does not respect. Then redoing the study.
What experience buys you: endpoints scoped to predicate, statistical methods that survive review, sample size justifications that hold up to deficiency letters. Inclusion criteria, reference standards, primary and secondary endpoints, and comparisons against human readers all designed up front.
Clinical Performance Assessment Report 🔗
First-time pain: panicking when the device misses a secondary metric and rewriting endpoints to match the output. That is exactly how teams lose clearance.
What experience buys you: the judgment to justify a missed secondary, defend the device’s safety and effectiveness, and clear the submission anyway. That is exactly what we did.
Truthful and Accuracy Statement 🔗
First-time pain: overthinking a form whose only correct answer is the truth.
What experience buys you: a one-pager. Tell the truth. Move on.
MDUFMA Cover Sheet 🔗
First-time pain: assuming the user fee is paid at submission. It is not. It can be paid in advance, and it goes up almost every October 1.
What experience buys you: paying before the increase, and not getting blocked by a government shutdown the way many teams were in October 2025, when payment processing was frozen and new 510(k) submissions could not proceed.
Package Labeling Justification 🔗
First-time pain: writing this section as if it required research.
What experience buys you: one sentence. “_____ is a Software as a Medical Device, and therefore, has no physical form that requires a package label.” Move on.
K232613 Additional Information AINN 🔗
First-time pain: a hold letter arrives roughly 3 months after submission with 180 days to respond, and you cannot tell which deficiencies are real and which are misunderstandings. Most teams answer everything as if it were equally serious.
What experience buys you: triage. On this submission, FDA asked for Bland-Altman plots, mean absolute error, Dice histograms, Hausdorff distance, reference standard clarifications, workflow descriptions, and cybersecurity rework. They also rejected our argument that the software was not a “cyber device”. Experience tells you when to add tests, when to clarify, and when to pivot.
AINN Clarification Meeting Agenda 🔗
First-time pain: not knowing you can request a teleconference with FDA within 10 days of the AINN. Most first-time teams skip it, assume the agency is omniscient, and treat silent disagreement as a strategy.
What experience buys you: the meeting, an agenda that resolves deficiencies before you spend a quarter rebuilding evidence, and the confidence to push back when a deficiency is a misread. FDA reviewers are human. They make mistakes, skim too fast, and fall into confirmation bias. Treat them that way.
Cybersecurity Management Plan 🔗
First-time pain: trying to argue your way out of being a “cyber device”. We tried. FDA disagreed. That is several weeks of AINN rework that did not need to happen.
What experience buys you: starting with the assumption you are in scope, scoping cybersecurity to the actual risk, running monthly vulnerability reviews, applying STRIDE for threat modeling, producing an SBOM in SPDX, and not getting caught flat-footed in the AINN.
Clinical Performance Assessment Report Rev C 🔗
First-time pain: FDA requests an additional analysis you did not plan for. You do not have the pipeline, the data structure, or the time. You rebuild end to end while the clock runs.
What experience buys you: a pipeline that already anticipates the request. We had it. We ran the additional analysis, updated the report, and moved on.
Interactive Review 🔗
Interactive Review is good news. FDA has decided your application is close enough to clearance that they will let their 90-day clock run instead of putting you on another hold.
First-time pain: an FDA email Friday afternoon, due Monday morning. Teams without bandwidth miss the response and lose ground. Teams without expertise answer the wrong question and create new deficiencies.
What experience buys you: someone whose job is to answer FDA emails over the weekend, accurately, the first time.
The Real Cost of the First-Time 510(k) Tax 🔗
Add it up. A 70-page Product Development Plan. A 70-page Risk Management Plan. 52 pages of hazards. Test infrastructure for labeling-satisfiable requirements. Traceability theater. A wrong call on cybersecurity. A hold letter you answer slower than necessary. An Interactive Review you stumble through.
This is 12 months minimum. For most first-time teams, more. It is also the most common reason teams run out of runway before clearance.
The teams that clear quickly are not the ones with more engineers. They are the ones with regulatory experience in the room from day one. That experience compresses the work, kills the busywork, and prevents the misreads that turn three-month deficiencies into nine-month ones.
Your engineers are not the problem. The first-time tax is.
Need help? 🔗
Don’t spend a year learning 510(k) the hard way.
We have cleared AI/ML SaMD 510(k)s end to end in under 12 months. We have turned hold letters into clearances in three. We have submitted 510(k)s in seven weeks. Speed and certainty are not marketing language for us. They are the guarantees on our engagements.
If you do not want to pay the first-time 510(k) tax, do not pay it alone.
