SBIR and STTR are US non-dilutive funding programs for small businesses doing high-risk R&D with commercial potential. For deeptech startups, they are often the cleanest way to fund technical proof before a venture round, customer deployment, or larger demonstration grant.
SBIR/STTR is not one grant. It is a family of programs across federal agencies, each with different topics, review culture, budget limits, timelines, and commercialization expectations. A strong startup does not search for SBIR in the abstract. It searches for the agency whose mission and review criteria match the next technical milestone.
Use this guide with the deeptech funding roadmap, the TRL levels guide, and the grant budget template.
Program fit
SBIR/STTR fits best when the next milestone is technical evidence, not general company growth.
The program is built for innovation risk. If the work is mainly sales hiring, routine product customization, marketing, or normal operating expense, SBIR/STTR is probably wrong. If the work is feasibility, prototype development, validation, agency-relevant testing, or technical de-risking, it may fit.
- Use SBIR/STTR for technical proof. The strongest projects ask for funding to answer a hard technical question that matters to customers or a federal mission.
- Do not use it as generic runway. Reviewers expect a bounded R&D project, not a request to keep the company alive.
- Tie the project to commercialization. Even when the work is technical, the application must explain what market, agency, or customer path opens after the milestone.
- Expect agency differences. NSF, NIH, DoD, NASA, DOE, USDA, and other agencies care about different problems and evidence.
SBIR vs STTR
| Program | Plain-English difference | Founder implication |
|---|---|---|
| SBIR | Small business leads the R&D project. | Best when the company can do the core work internally or with contractors. |
| STTR | Small business formally collaborates with a research institution. | Best when university or lab capability is central to the work. |
| Both | Non-dilutive R&D funding with commercialization expectations. | The proposal must show technical merit and a credible path beyond the award. |
The distinction matters for IP, workshare, principal investigator assumptions, subcontracting, and project control. A university spinout should check STTR early if the research institution still owns critical capability or IP. A startup with its own technical team may prefer SBIR if it can execute without a formal research partner.
Phase logic
Most founders should think about SBIR/STTR in phases. Phase I usually tests feasibility. Phase II usually expands development after Phase I-style evidence exists. Later commercialization is not automatic; companies often combine Phase II evidence with customers, strategic partners, procurement, venture capital, or other grants.
| Phase | Typical question | Evidence reviewers expect |
|---|---|---|
| Phase I | Can this concept work well enough to justify deeper development? | Clear technical hypothesis, early evidence, feasible work plan, credible team. |
| Phase II | Can the company develop and validate the technology further? | Phase I results, stronger milestones, bigger budget logic, commercialization plan. |
| Commercialization | Can the result become a product, contract, or deployment? | Customer discovery, pilots, partner letters, regulatory path, procurement or market logic. |
Eligibility
Eligibility is not just company size. Founders should check ownership, location, PI employment, work location, research partner rules, agency-specific requirements, and whether the project is responsive to a solicitation or topic. This is where many apparently strong startups lose time.
- Check the applicant entity first. Make sure the applying company, ownership, and US small-business status meet the program rules.
- Check the workshare. SBIR and STTR treat internal work, subcontracting, and research-institution participation differently.
- Check the PI rule. Some agencies have specific expectations for principal investigator employment and commitment.
- Check topic responsiveness. A technically strong project can still be a poor fit if it does not answer the agency topic.
Agency fit
Agency fit is the center of SBIR strategy. NSF often supports broad deep technology with commercial potential. NIH is strongest for biomedical and health technologies. DoD and NASA topics are more mission-specific. DOE may fit energy, climate, materials, manufacturing, and infrastructure problems. The same startup may be fundable by one agency and invisible to another.
| Agency path | Good fit | Bad fit |
|---|---|---|
| NSF | Frontier technology with broad commercial potential. | Incremental software or services with weak technical novelty. |
| NIH | Diagnostics, devices, therapeutics, digital health, research tools. | Non-health markets or projects without credible biomedical relevance. |
| DoD/NASA | Mission-relevant robotics, autonomy, sensors, space, materials, defense. | Generic commercial products with no agency use case. |
| DOE | Energy, climate, manufacturing, grid, materials, industrial decarbonization. | Projects without energy, industrial, or national-lab relevance. |
Application strategy
A good SBIR/STTR application is both technical and commercial. The technical narrative must explain what is hard, what has been proven, what remains uncertain, and how the project will reduce that uncertainty. The commercialization plan must explain who cares if the technical work succeeds.
Use the how to write a grant proposal guide for the full writing workflow. For SBIR/STTR, add an agency-fit paragraph early: why this agency, why this topic, why this company, why this milestone now.
- Start with agency mission. Technical excellence is not enough if the topic or agency does not care about the use case.
- Define Phase I proof tightly. The application should name the experiment, success metric, risk reduced, and evidence output.
- Keep commercialization credible. Reviewers should see who benefits, why they will adopt, and how Phase I evidence supports the next step.
Budget and timing
SBIR budgets should follow the work packages. Personnel, subcontractors, research partner costs, materials, equipment, travel, and indirect costs should all connect to milestones. If the budget looks like company overhead, the project looks weak.
| Budget item | Reviewer concern | Better framing |
|---|---|---|
| Founder salary | Is this general runway? | Tie effort to technical work packages and reporting. |
| Subcontractor | Is the company outsourcing the innovation? | Explain specialist capability and deliverables. |
| Materials | Are quantities guessed? | Base on build-test cycles and supplier assumptions. |
| Travel | Is it sales travel? | Connect to required testing, partner work, or agency meetings. |
Mistakes
- Applying to the wrong agency. A project can be technically excellent and still fail because the mission fit is weak.
- Treating Phase I like a mini seed round. Reviewers are funding a feasibility project, not a broad company plan.
- Hiding the technical risk. SBIR/STTR exists because risk remains; the proposal should name and structure it.
- Underwriting commercialization. A vague market paragraph is not enough; show customer, agency, or procurement logic.
- Ignoring the research partner mechanics. STTR and subcontracting rules affect control, budget, IP, and workshare.
How to decide if it belongs on the roadmap
The practical question is not whether SBIR/STTR sounds attractive. The question is whether it funds the next milestone the company already needs. For US deeptech startups, that milestone is usually technical feasibility or prototype validation. If the funding route does not move that milestone forward, it may create activity without strategic progress.
Use the company roadmap as the decision filter. A founder should be able to say: this programme funds this project, this project creates this evidence, and this evidence changes the next customer, investor, regulatory, or partner conversation. Without that chain, the opportunity is probably not ready.
| Decision question | Good sign | Bad sign |
|---|---|---|
| Does the scope fit? | The call language clearly matches technical feasibility or prototype validation. | The team is stretching the story to avoid saying it is general runway, marketing, or routine product work. |
| Does the company have enough evidence? | The application can cite preliminary technical data, a clear experiment plan, and commercialization logic. | The application mostly relies on ambition, market size, or founder confidence. |
| Will the result matter? | The milestone unlocks a clearer next funding, customer, partner, or regulatory step. | The result is a report or deliverable nobody outside the grant will care about. |
| Can the team deliver? | Owners, partners, budget, and timeline match the work packages. | The work depends on unnamed partners, missing hires, or unsupported assumptions. |
Minimum evidence pack
Before drafting, build a minimum evidence pack for SBIR/STTR: fit notes, proof of eligibility, technical evidence, work-package plan, budget assumptions, and the commercialization reason this project matters.
This does not mean every risk must already be solved. Grants exist because uncertainty remains. The point is to show that the uncertainty is specific and fundable. A weak application says the company needs money to continue development. A stronger application says exactly what will be proven, why it is hard, what evidence already exists, and how the funded work changes the company's maturity.
- Fit memo. Write one page explaining why SBIR/STTR is the right funding route and why the current call or programme fits the project.
- Evidence inventory. Collect data, tests, partner input, customer signals, technical diagrams, quotes, and prior results before writing prose.
- Risk map. Name the technical, market, regulatory, manufacturing, and delivery risks the project will reduce.
- Budget basis. Tie people, subcontractors, materials, equipment, travel, and indirect costs to work packages.
- Next-step logic. Explain what the company can do after the grant that it cannot credibly do today.
Founder example
A sensing startup with early bench data can use SBIR/STTR to test performance in a relevant environment before raising a priced round.
The useful version of that example is not just "apply for a grant." It is a sequence: identify the missing evidence, find the programme that funds that evidence, write the work packages around the evidence gap, cost the work realistically, and explain how the result changes the business. That sequence is what separates strategic non-dilutive funding from grant chasing.
| Weak application logic | Stronger application logic |
|---|---|
| We need SBIR/STTR because non-dilutive funding is available. | We need SBIR/STTR because it funds technical feasibility or prototype validation, which is the next evidence gap in our roadmap. |
| The market is large and our technology is innovative. | The first adopter has a concrete problem, current alternatives are weak, and this project proves the technical condition needed for adoption. |
| The team will develop and validate the product. | WP1 builds the subsystem, WP2 tests it under defined conditions, WP3 validates with a partner, and each milestone has a pass/fail threshold. |
| The budget reflects project needs. | Each cost line maps to a task, evidence output, owner, and timing assumption. |
How to use this with the rest of the Joltoo grant library
This article should not be read alone. Start with the grant eligibility checklist if you are unsure whether the company can apply. Use the grant search workflow to build a shortlist. Use the how to write a grant proposal guide when you begin the narrative. Use the grant budget template when the financial story needs to match the work plan.
Use the library as a sequence, not a pile of tabs. First check eligibility, then build a shortlist, compare non-dilutive funding with other capital, turn the chosen opportunity into a milestone plan, and only then write the application and budget. That order keeps the team from polishing a proposal before it knows whether the grant is the right instrument. If the route still feels ambiguous, use the linked guide that answers the weakest point: eligibility for fit, discovery for alternatives, roadmap for timing, writing for reviewer logic, and budget for delivery proof. That keeps internal discussion focused on a decision rather than another round of generic funding research.
What the reviewer should be able to repeat
After reading the application, SBIR/STTR reviewers should be able to repeat the core case without rereading the page: who is applying, what will be built or tested, why the work fits the programme, what evidence exists today, what evidence the grant will create, and what changes after the project. If that story is not repeatable, the draft is probably too diffuse.
This repeatability test is useful because reviewers are comparing many applications under time pressure. They may not remember every technical detail, but they should remember the central logic. The application should make agency topic fit, technical risk, commercialization, and small-business eligibility obvious in the headings, first sentences, tables, and budget narrative.
- One-sentence fit. The project should have a plain-English sentence that explains why this funder should care.
- One evidence gap. The proposal should name the main uncertainty the funded work will reduce.
- One milestone chain. The work packages should show how one result enables the next.
- One commercial next step. The reader should know what customer, partner, investor, or regulator conversation improves after the project.
- One compliance check. Eligibility, deadline, portal, budget, and attachment requirements should be resolved before final prose.
Submission package checklist
A strong submission package is more than the main narrative. Founders should prepare the pieces that make a Phase I feasibility result or Phase II development milestone credible: a scope memo, evidence folder, milestone table, budget basis, partner or advisor inputs, risk register, and source links for official rules. These artifacts make writing faster and make the final review more precise.
| Package item | Why it matters | Minimum standard |
|---|---|---|
| Scope memo | Prevents drift from the official call or programme. | One page linking project aims to funder scope. |
| Evidence folder | Keeps claims grounded. | Data, tests, customer notes, partner letters, diagrams, or prior results. |
| Milestone table | Turns ambition into a scorable plan. | Owner, date, output, success metric, and dependency. |
| Budget basis | Makes costs auditable. | Rates, quotes, effort assumptions, quantities, and eligible-cost notes. |
| Risk register | Shows the team understands uncertainty. | Technical, market, regulatory, partner, and delivery risks with mitigations. |
When to move to another guide
Use this guide for the specific decision in the title, then move to the adjacent guide when the question changes. If the next question is discovery, go to how to find deeptech grants. If it is eligibility, use the grant eligibility checklist. If it is writing, use the grant application guide. If it is budget, use the grant budget template.
That handoff matters because founders lose time when one page tries to answer every funding question. The better workflow is narrow: answer the current decision, capture the evidence needed for that decision, and move to the next guide only when the project has reached the next funding question.