NIH RFA-OD-24-011: NIH Research Software Engineer (RSE) Award (R50)

NIH RFA-OD-24-011: NIH Research Software Engineer (RSE) Award (R50)

The NIH Research Software Engineer (RSE) Award is an uncommon but increasingly important federal mechanism: it funds people, not gadgets or publications. If your team relies on software to advance biomedical research and you need software capability that is durable and credible, this is one of the few NIH awards built explicitly around that role.

Unlike many mechanisms centered on scientific hypotheses or new biological findings, this opportunity exists to support career-stage research software professionals embedded in NIH-funded environments. The NOFO explicitly frames the goal as career continuity for exceptional RSEs and the development of software that can be sustained, shared, and reused across projects.

At a practical level, this is often most relevant for teams that already have a funded NIH project and need senior engineering leadership to improve code quality, architecture, tooling, documentation, and reproducibility in ways that improve research productivity. The award does not replace project funding; it augments it by underwriting the RSE’s time and core software contributions.

Key details at a glance

What this opportunity is and what it is not

This is not a classic investigator-led research grant where the PI proposes a whole set of experiments and expects to hire multiple staff and build a large research program. It is instead a focused career-and-capability mechanism. The NOFO states that the award is designed for RSEs in research settings who are not in a traditional independent-investigator track, and it emphasises stable progression in software career pathways.

What the opportunity is:

• A mechanism to fund a person’s software contribution inside existing NIH-funded research.
• A way to formalize protected time for software craft: architecture, maintainable code, documentation, and dissemination practices.
• A tool for institutions to retain high-quality engineering talent where software was previously treated as incidental support.

What it is not:

• Not limited to startups, commercial prototypes, or venture activity.
• Not a broad technology grant with large equipment stacks and diversified budget categories.
• Not a direct grant for general project teams where the RSE is just one minor staff line.

The NOFO explicitly says no clinical trials are allowed. That is a structural constraint that can matter for teams in translational environments working with trial protocols. If a proposal requires trial-linked software only as secondary implementation, review scope may still be okay, but if the project includes trial arms as a central deliverable, this is usually a mismatch.

The most important strategic interpretation: NIH funds the RSE role and expected outputs connected to research software impact, not a conventional bench-science “complete story” with extensive ancillary research spending.

Who should apply: eligibility and fit

The opportunity has two levels of eligibility:

1. Organizational eligibility
2. Candidate/position eligibility

Organizationally, the page includes a broad list of U.S.-based eligible entities (HEIs, nonprofits, local governments, for-profits including small businesses, federal agencies, and more), with a hard exclusion: non-domestic foreign organizations are not eligible to apply.

At the candidate level, the NOFO is explicit:

• The RSE should have a full-time, non-tenure-track position in an academic institution.
• Applications that do not identify the RSE as the PD/PI contact are non-responsive.
• The application must include a support letter from an NIH-funded project PI the RSE will collaborate with, and two additional recommendation letters from investigators, project leaders, or equivalent.

So the best-fit applicant is typically:

• A software engineer already working inside biomedical research programs,
• with evidence of software contributions tied to NIH-funded projects,
• who wants a clear, funded path for 2-3 years of sustained engineering work.

A common misunderstanding is that this is primarily a “student” or “junior researcher” award. In practice, it is more about depth and demonstrated contributions than title alone. The applicant can be early or mid-career, but the record is assessed on demonstrated impact and fit to NIH-supported research problems.

What NIH will fund (and what it will not)

The funding controls are unusually clear:

• Up to $300,000 combined direct cost budget for up to three years.
• No more than $200,000 direct costs per year.
• Salary support for the RSE is the center of cost planning.
• Travel support up to $2,500/year is allowed.
• No other expenses are typically supported (as reflected by the strict budget focus in the NOFO summary).

In concrete planning terms, this means that this is a low-frill program: proposals should not try to pack unrelated sub-awards, consumables-heavy pipelines, or broad infrastructure stacks unless directly and legally tied to the RSE’s work package. Budget narratives should focus on staffing time, concrete deliverables, and minimal travel for dissemination/coordination.

Your proposed project period can be up to 3 years. The NOFO explicitly allows this maximum duration. That means teams can plan for continuity beyond a single grant cycle, which is useful if software modernization requires iterative refinement, not just a one-off proof-of-concept.

Application process and system workflow

The NOFO requires electronic submission. In practical terms, the application package is obtained via ASSIST, Grants.gov Workspace, or institution-to-system solutions (S2S), and applications must be tracked with eRA Commons. Since this is a competitive NIH route, registration is a gating item, not an afterthought.

Core process steps

1. Confirm the organization’s registrations (DUNS successor identifiers and SAM-related obligations, as required in NIH workflows).
2. Open the RFA forms package via NIH systems and get the correct package for this NOFO.
3. Build a short but complete application package that focuses on:
   • RSE role and contributions,
   • supporting project context,
   • letters and endorsements,
   • budget justification with realistic effort and no unsupported categories.
4. Verify page limits and format constraints in the NIH application guide and NOFO notes.
5. Submit in a tracked system (ASSIST or Grants.gov Workspace path).
6. Archive all submission artifacts and be ready for post-submission material requirements.

The NOFO uses strict compliance posture: non-responsive applications are rejected before peer review. This is where many strong research narratives fail if role, letter, or budget specifics do not exactly match required structure.

Because deadlines are explicit and the window is tied to multiple annual cycles, most teams should target a full internal review date well before the official due date. The NOFO includes a reminder that registrations can take up to six weeks, which is a real constraint. In practice, late registration is the #1 operational risk.

How reviews will be judged

The review section differs from standard content-heavy research calls. It explicitly notes that proposals do not require preliminary data, specific aims sections, or full detailed research plans. That is a big advantage for many candidates, because review emphasis shifts from experimental planning to demonstrated competency and fit.

The review focus for this award includes:

• the RSE’s expertise and portfolio,
• suitability for the proposed NIH project,
• the value of the collaboration with the sponsoring project PI,
• recommendation quality and support documentation,
• expected contribution to the host organization and broader open development communities.

The page also notes general NIH review behavior: completeness first, then peer review filtering into discussable applications. So technical validity and compliance come before score.

For applicants, this means:

• Put the RSE’s portfolio and engineering decisions front and center.
• Make evidence concrete: code contributions, reusable libraries, reproducibility interventions, documentation systems introduced, workflow improvements.
• Show collaboration design (who will work with the RSE, and what value they unlock).
• Avoid pretending you are a traditional PI-led scientific hypothesis write-up.

Preparing a strong application: practical playbook

This is a review-optimized mechanism, so your strategy should align with what the NOFO actually asks for.

1) Position the RSE role with precision

Describe the role as a production-oriented research function:

• software architecture choices,
• workflow integration,
• testing and quality standards,
• user-facing training or onboarding,
• long-term maintainability.

Avoid over-framing as a pure coder role. The NOFO rewards engineers who can translate project goals into reliable software capacity.

2) Tie deliverables to NIH-supported projects

The award sits in the context of NIH funded programs. The RSE’s work should be anchored to real project outcomes that matter to one or more funded programs. Your narrative should answer:

• Which NIH-supported research questions are unlocked by this software role?
• What is the risk if this role is not funded?
• What happens by the end of year 1 and year 3?

3) Treat the letters as a primary scoring lever

Two specific requirements are structural:

• one letter from an NIH-funded PI partner,
• two letters of recommendation demonstrating contribution quality.

These should be coordinated before drafting starts. Weak letters are harder to fix than weak prose because review committees treat them as evidence quality signals.

4) Keep budget realistic and narrow

A common mistake is to pad cost lines that NIH clearly does not prioritize. The NOFO permits a very specific budget scope (salary + limited travel). Build your budget narrative around this and show why requested effort is minimal but sufficient.

5) Make the RSE track record measurable

Since the NOFO removes the requirement for preliminary data and specific aims in the traditional sense, your portfolio evidence should be measurable through impact and maintainability indicators:

• release cadence,
• code quality practices,
• reproducibility features,
• training delivered,
• transfer of software to collaborators.

Common mistakes and how to avoid them

Most failures in this NOFO are compliance or framing failures.

• Mistake: not defining the RSE as the contact PI.
  • Avoidable by checking the applicant role mapping before submission.
• Mistake: missing or weak recommendation letters.
  • Avoidable by briefing letter writers with specific review criteria.
• Mistake: overloading budget categories beyond permitted scope.
  • Avoidable by keeping budget to software engineer effort and allowed travel.
• Mistake: unclear relation to NIH-funded project.
  • Avoidable by including explicit tie-ins to concrete projects and project lead support.
• Mistake: weak submission compliance (registration, system routing, form mix).
  • Avoidable by using a calendar backward from the deadline and submitting early.

If an application is incomplete or non-responsive, it is not reviewed. That means you should treat compliance as part of the scientific strategy, not a clerical burden at the end.

2026/2027 timeline, review sequence, and readiness checklist

The NOFO currently lists a recurring application pattern through December 2026 with a review/award chain leading into 2027 starts and review milestones. Even if the current opening was earlier, this date pattern matters because teams can align internal approvals around one active cycle.

Suggested 8-week prep sequence

• Week 1–2: Confirm organizational eligibility and start registrations.
• Week 3–4: Define role outcomes, map to project PI and collaborators.
• Week 5–6: Collect evidence artifacts (repos, docs, metrics) and secure letter drafts.
• Week 7: Draft budget and submission forms; ensure page limits and required fields are exact.
• Week 8: Internal compliance pre-check, then submit buffer time before deadline.

For teams targeting an upcoming cycle, include this as an annual recurring task. The NOFO itself is updated over time; check the latest notices on the same page before submission.

Official links and next steps

• Official opportunity page (primary): https://grants.nih.gov/grants/guide/rfa-files/RFA-OD-24-011.html
• NIH How to Apply guide: linked from the NOFO
• Grants.gov Workspace and ASSIST pathways: linked from the NOFO
• NIH Grants Policy Statement (context for post-award and compliance): linked from the NOFO

If your team is in a biomedical lab and already has NIH funding where software quality is currently a bottleneck, this is often a better strategic fit than adding software effort as an add-on in a traditional scientific application. It is especially useful when the team already has compelling software outcomes but cannot justify a full replacement of project strategy.

FAQ

Is this for teams outside the U.S.?

No. The NOFO excludes non-domestic organizations from applying as entities, although foreign components that are defined in NIH policy can be allowed in limited ways.

Is clinical work prohibited?

The NOFO is marked “Clinical Trials Not Allowed.” If your proposal relies on clinical trial conduct, this is typically outside scope.

Can it support more than one RSE?

The call language focuses on a single RSE position as part of the application, with budget and scope tightly constrained. Treat multi-person plans as unlikely unless justified within the same award structure.

Are renewals accepted?

Yes, renewal application types are shown as allowed in the NOFO structure, but each cycle is reviewed against current requirements. You still need full compliance and current documentation.

Can the award support travel?

Yes, but only up to $2,500 per year (as specified in the NOFO budget section).

What should institutions do first?

Complete registrations immediately and line up the two required recommendation letters and one PI support letter before drafting the full application narrative.

In short: this is a role-focused grant with constrained budget logic and high process discipline. For teams that need stable software capability and demonstrable engineering leadership in NIH science, it is one of the few mechanisms that directly funds that reality.