Location: Remote (U.S. only, excluding Alaska and Hawaii)
Job Type: Full-time
Innolitics is a remote-first company specializing in medical device software development and FDA regulatory consulting. Since 2012, we've partnered with medical device companies to bring new technologies to market. Our team of engineers, consultants, and domain experts works at the intersection of software engineering and regulatory compliance.
Agentic AI tools like Claude Code and Codex are changing the day-to-day experience of software engineering. We see this as an opportunity, not a threat. We are a growing, collaborative team that is actively learning how to use these tools to produce robust, traceable, high-quality systems where correctness, safety, and documentation matter.
We are hiring a principal engineer who has already shipped regulated medical device software. You will lead client projects from concept to clearance. On a typical week, you will write code for a new SaMD product, review a client's software development plan against IEC 62304, draft a software description for a 510(k), and explain to a client's CEO why a change requires a new submission. You will be the person in the room who understands both the code and the regulation.
Someone who
Experience with ISO 14971, IEC 62366, FDA cybersecurity guidance, AI/ML PCCPs, or cloud infrastructure with Terraform is a plus.
We only take on projects we believe improve the world. Recent projects include software for radiation oncology clinics, a device that detects ear infections, open-source software used by neurosurgeons and researchers, an AI cardiomegaly detector that went from concept to FDA clearance in under 12 months, and software for tracking metastatic cancer. See our portfolio for more.
The salary for the position is $200,000–$250,000/year, depending on education and experience. We also have a 10%–12% annual bonus tied to hitting billing utilization targets.
We operate exclusively in the healthcare sector and do not take on debt, which shields us from boom and bust economic cycles. We have never had to lay off employees because of a recession.
We're tight-knit, profitable, and growing quickly. If you work with us you can participate in our growth and help define the direction we move in. You can wear many hats and contribute to the company beyond software development.
Work with a team of talented, mission-driven engineers who will help you become a better engineer. We're a close-knit group, despite being fully remote.
We invest in the personal and professional development of all our team members. We dedicate two hours on Wednesday afternoons to ongoing learning. Here is a list of our previous learning topics. You'll also have opportunities to change projects from time to time.
We've been remote-only since 2012, so we know how to run a remote company effectively. You can live anywhere in the United States except Alaska and Hawaii.
We provide a 401(k) with Traditional and Roth options. Innolitics contributes 3% of your salary annually once you've worked with us for six months, vesting immediately. The plan includes very low-cost index funds and we cover all plan costs.
We provide company health insurance (details in our handbook). We reimburse internet costs up to $1,200/year and provide a $750/year equipment stipend.
Use the Apply Now button below to submit your resume and cover letter. Your cover letter should be three or four short paragraphs explaining why this position in particular interests you and why you're a great fit.
We'll read your email and review your resume. If we don't think you're a good fit, we'll let you know. We probably won't respond if you don't live in the US or haven't explained why you want to work at Innolitics in particular.
If it looks like you're a good fit, we'll get in touch. The interview process involves a couple of interviews and a take-home activity writing short documents for an imaginary medical device. We'll also require two reference checks.
Send your resume and cover letter.
What the job looks like
The posting above lists what we look for. This part shows the work itself: the disciplines you own and the tasks you do at each stage of a project. Read it and decide whether you would enjoy doing this work.
Knows
Engineering
You can do every task in this lane yourself and lead others through it.
Knows some
CybersecurityRegulatory
You do parts of this work and review the rest.
Aware of
ClinicalQuality
You know what these lanes produce, when your work depends on it, and whom to ask.
Scroll sideways to see all eight stages.
IEC 62304 lifecycle. Read the client's code and models.
For a principal engineer: Knows
Agree the device boundary with regulatory and cybersecurity before writing the development plan, and confirm with quality whose QMS it runs under. The boundary sets how much code needs documentation.
Open the task page: decisions, examples, articlesYour lane, stage by stage
Each stage lists the engineering work, the decisions you make, and the one conversation with another discipline that most often decides whether the stage goes well.
Kickoff and plan · Month 0–1
The engineering lead writes the product development plan. It sets the IEC 62304 lifecycle, the design phases and their reviews, configuration management, the traceability plan and the verification and validation approach. Engineers also read the client's existing code, models and data pipeline to judge what can be carried into the device and what must be rebuilt under design controls. The plan fixes where training and test data are stored and who can reach them, so the test set stays independent from the first day.
Decisions you make:
Study design and pre-sub · Months 1–4
Engineers describe each model and each deterministic algorithm: its inputs, outputs, architecture, training data and how the pieces chain into the device output. They run the current model on a pilot set to estimate the size and spread of its error, which the biostatistician turns into a powered sample size. With the clinical team they design how the reference standard is produced for training data and for the test set, including the number of readers, how they read and how disagreements are resolved.
Decisions you make:
Read more:
How each decision is made: Algorithm description, pilot data and truthing design
Risks and requirements · Months 2–4
Engineers write the software requirements specification, the architecture diagram with its software items, and the interfaces to systems outside the device. Risk workshops bring engineering, clinical and regulatory staff through each hazard and turn each design control into a requirement that can be verified. The algorithm is packaged in a container so the runtime used in verification is the runtime that ships.
Decisions you make:
Read more:
How each decision is made: Requirements, architecture and risk workshops
Build sprints · Months 4–14
Sprints start with the features that carry the most clinical or technical risk, so problems surface while the design or the claim can still change. Each risk and security control is built as a requirement, with tests written alongside the code and checked in code review. Before test-set results are seen, the team freezes the model weights and records the exact artifact that will be tested.
Decisions you make:
Read more:
How each decision is made: Build sprints, risk controls and the weight freeze
Verification · Months 14–16
Engineers execute the approved verification protocols against one tagged build and record pass or fail, tester, date and the requirements each test covers. The locked model is run once on a sequestered test set that played no part in training or tuning, and the results are compared with the reference standard against acceptance criteria written before the data were unblinded. Every known defect or behavior that departs from expectation and is still open in the submitted version goes into the unresolved anomalies list with its safety and security impact and the reason it is left in.
Decisions you make:
Read more:
How each decision is made: Verification run and standalone test
Validation and submission · Months 16–17
Engineering declares one version as the release that goes into the submission and stops changing it. The team supports the clinical analysis by running the frozen device on study cases, exporting outputs in the format the statistician needs, and answering questions about failures and outliers. The validated build is archived with everything needed to reproduce it, including container images, model weights, dependency pins, test data and expected outputs, and the version history records what was released.
Decisions you make:
Read more:
How each decision is made: Frozen release and archived build
FDA review · About 5 months
When FDA sends an additional information request, engineering re-runs the frozen model on the same test set to produce the analyses the reviewer asked for, such as agreement plots, error distributions, extra metrics and subgroup breakdowns. Outliers are pulled and reviewed case by case to explain the failure mode. Where a claim or feature cannot be supported in the response window, the team removes it. Where the reviewer finds a gap in requirements or tests, engineering adds the requirement, writes or rewrites the test, and releases a new verified version under change control.
Decisions you make:
Read more:
How each decision is made: Answering performance deficiencies
After clearance · Ongoing
After clearance, every software release goes through change control with a documented regulatory assessment, verification scaled to the change, updated labeling and an updated SBOM. Model retraining or new input sources are allowed without a new submission only when an authorized PCCP covers them and the modification protocol is followed exactly. Engineering also collects field data such as logs, failures, complaints and performance on new sites, so drift or new failure modes are caught and fed back into risk management.
Decisions you make:
Read more:
How each decision is made: Releases, retraining and monitoring