How SBIR Funding Works for Software Startups (October 2026)

SBIR is not a grant program you apply to in the abstract. It is a set of federal rules that require participating U.S. agencies to reserve a slice of their research budgets for small companies, and how SBIR funding works for software startups comes down to this: you match a real R&D project to a published topic solicitation, submit a proposal against it, get reviewed on technical merit and feasibility, and if you win, you sign a Notice of Award and draw down non-dilutive money in phases.

There is no equity taken, no repayment due, and no guaranteed result. What you get is paid, contract-bound R&D plus a paper trail that later helps you land actual government customers. Most of the confusion founders hit comes from two places: expecting a generic grant application, and assuming a software product with no prototype is a good fit.

This guide walks through what SBIR is, who qualifies, how the three phases differ, what happens during review, what your money is allowed to pay for, and the compliance work that starts the day you win. Last reviewed October 2026 against agency solicitations published on sbir.gov. Check the live solicitation before you commit budget, because topics, deadlines and award sizes move every cycle.

Table of Contents

• What Is SBIR Funding?
• How SBIR Funding Works for Software Startups
• Is Your Software Startup Eligible?
• Which SBIR Phase Should You Target?
• How SBIR Funding Works for Software Startups During Proposal Review
• What Happens After You Win an SBIR Award?
• How SBIR Funding Works for Software Startups at the Award Stage
• What Can SBIR Funds Be Used For?
• What Compliance Rules Must Software Startups Follow?
• What Are the Main Risks and Limitations?
• How to Prepare a Strong SBIR Proposal
• Frequently Asked Questions
• Is SBIR funding a grant?
• Can a software startup receive SBIR funding?
• Can a non-U.S. founder apply for SBIR funding?
• Does SBIR funding dilute startup ownership?
• What happens after a startup completes Phase I?
• What is Phase III of the SBIR program?
• What to Do First

What Is SBIR Funding?

SBIR stands for Small Business Innovation Research. Congress created it so that a measurable share of federal research and development spending goes to small companies rather than only to universities and large primes. It has been around since 1982 and has been renewed and amended several times since.

The pairing most people run into is SBIR and STTR, Small Business Technology Transfer. They are sister programs with the same three-phase shape. The difference is structural: SBIR requires the small business to perform the research itself, while STTR requires a formal research institution, usually a university, to own and lead a portion of the work. Software startups usually sit more naturally in SBIR, but a spinout with a lab partner can qualify for STTR.

Here is the framing that matters for a software company: SBIR funds research and development, not product development. The line between the two is the whole game. Building a working prototype of something technically uncertain is R&D. Adding a dashboard, adding onboarding, adding another customer integration, or making the product faster is not, and reviewers reject proposals that read like the latter.

Public sector startup people often call the program America’s Seed Fund, and while it is not venture capital, it is the earliest and often cheapest source of capital for a deep-tech company that cannot yet raise a priced round.

How SBIR Funding Works for Software Startups

The process runs in a fixed order, and most founders who get frustrated simply enter it at the wrong point.

1. Confirm you fit a live topic solicitation. Agencies publish topics with specific R&D goals. If your work does not answer a published topic, there is nothing to submit against.
2. Confirm small business eligibility. U.S. for-profit status, size under the applicable SBA standard, majority U.S. ownership and control, and a Principal Investigator whose primary employment is with your company.
3. Register the company where federal work requires it. A Unique Entity ID (UEI) through SAM.gov, a CAGE code for awards, and banking details. This takes longer than founders expect, so start early.
4. Write the proposal against the solicitation instructions. The solicitation, not your preferences, decides the format, the page limits, the topics and the required deliverables.
5. Submit and wait through agency review. Merit review looks at technical merit, feasibility, team, and how well the proposal answers the topic.
6. Negotiate the award. If selected, you and the agency agree the scope, budget and reporting terms before anything is funded.
7. Perform the R&D, report, and close out. Then pursue Phase II, then pursue real contracts in Phase III or on the open market.

Solicitation deadlines are set per topic, not per program, so there is no single annual SBIR date to block out. Some topics run twice a year; some appear once.

For civic and municipal work specifically, the routing is different. City and state open data programs, 911 modernization, transit sensing, and utility software increasingly show up in Department of Transportation, Department of Homeland Security, Department of Energy, and NIST topics, and those topics reward teams that can actually run a pilot in a real jurisdiction.

Is Your Software Startup Eligible?

Score yourself line by line. A single failure usually ends the review.

• A U.S. for-profit entity. Foreign entities and nonprofits cannot apply directly. A U.S. subsidiary structure needs real control by U.S. persons, not just a registered address.
• Size under the applicable SBA standard. The threshold depends on your NAICS code and the size standard the solicitation names. Plenty of well-funded software companies have failed this test at the wrong size category.
• Majority ownership and control by U.S. citizens or permanent residents. Foreign founders can absolutely hold substantial equity, but control has to sit with U.S. persons.
• A Principal Investigator primarily employed by the company. This is the requirement that quietly disqualifies many university spinouts. If the PI is a full-time professor and the company is their secondary employer, the proposal is out. Founders note this repeatedly in SBIR communities as a painful surprise.
• Genuine technical uncertainty. You should be able to state what is not yet known, what you will test, and what result would count as failure.
• A live topic match. Not a broad alignment with agency mission, an actual topic.
• Registration in place. UEI, SAM.gov, CAGE.

Now the honest part. Most pure SaaS is not eligible, and pretending otherwise wastes two months of founder time. A subscription dashboard, a workflow tool with a new integration, and a redesign of an existing product are not R&D and will not survive review. Software startups win when there is a hard technical question underneath: an algorithm that may not converge under real-world sensor noise, a cybersecurity tool that must find a vulnerability class nobody has documented, a computer vision model that has to work in low light and weather, a simulation or digital twin that has never been run at city scale.

If your honest description of the work starts with “we will build,” rewrite it around “we will determine whether.” That single change is the difference between a proposal that scores and one that gets returned without review.

Which SBIR Phase Should You Target?

Phase I tests feasibility, Phase II builds and demonstrates, and Phase III is where SBIR money stops and ordinary procurement begins. Here is the same picture in one view, using the ceilings agencies most commonly publish.

Phase	Purpose	Typical award	Typical length	What it pays for
Phase I	Feasibility and proof of concept	Up to roughly $305,000	6 to 12 months	Testing whether the technical approach works at all
Phase II	Prototype development and demonstration	Commonly $1,000,000 to $2,000,000+, some topics allow more	12 to 24 months	Building the working system and proving it in a representative environment
Phase III	Commercialization, scaling, and delivery	No SBIR funding of its own	Whatever the contract says	Production versions, fielding, integration into government operations

Each solicitation states the actual number for its topic, so treat the table as a budgeting shape rather than a promise. The number in the solicitation wins over any summary you read elsewhere, including this one.

Most software startups go after Phase I first because it is cheaper in time and cheaper in reputational risk. Some agencies also allow a direct-to-Phase II route for companies with prior R&D, but it is narrower and typically requires more evidence, and it is not a shortcut around review.

How SBIR Funding Works for Software Startups During Proposal Review

Review is the step founders worry about most and understand least. Typically a proposal gets scored on the merits of the idea and the quality of the plan, sometimes with a commercial or management review layered on top depending on the agency.

Reviewers are usually external subject matter experts plus a program officer. They read for a small number of things:

• Responsiveness. Does this answer the published topic, in the language the topic used?
• Technical merit and novelty. Is the approach genuinely new, or an incremental rebuild?
• Feasibility. Can this team actually do this work in this time on this budget?
• R&D risk. Is the unknown real, or is the project pretending to be research?
• Team and environment. Do the people and the company setting support the plan?
• Commercialization. Is there a credible path to a customer, and is it more than one sentence?

Some agencies allow a short rebuttal window after the technical review returns comments but before a decision. If your solicitation offers one, it is the only sanctioned way to respond, and it should fix a factual error or a scoring misread, not argue taste. Read the solicitation carefully; do not assume a rebuttal exists because you have seen one agency use it.

The rejection patterns software proposals actually show up in are consistent. Off-topic proposals. Thin commercialization sections with no named customer path. No letters of support from anyone who has used or intends to use the system. Novelty theater, where the innovation claim is a buzzword rather than a specific technical difference. And budgets that look like a software sprint plan instead of an R&D plan, with no real risk.

What Happens After You Win an SBIR Award?

Selection is not the finish line. Between a selection notice and usable money there is negotiation, and founders who assume the money is already theirs get burned by the delay.

The agency and the company agree the statement of work, the milestones, the budget line by line, the payment terms, and the reporting schedule. The Notice of Award is the document that makes spending lawful. Until it is signed and the funding is obligated, do not hire against it and do not order against it.

After that, the practical work looks like this:

• Run the project to the milestones in the award. Scope creep is not a conversation, it is a modification request.
• Report on schedule. Most agencies name a reporting system, often PPRS or an agency portal, and expect interim technical and financial reports.
• Keep good records. Timesheets by task, receipts, and a running budget-versus-actuals file. Small teams that skip this during the project scramble at closeout.
• Close out properly. A clean closeout is part of the record evaluators and program officers look at later.
• Watch data rights. Background IP stays yours. The government typically takes rights it needs for its own purposes, and the solicitation and award spell out exactly what that means.

For a software company the data rights question deserves a real conversation before you sign, not after. Understand what the government may do with your code, your model weights, and data you bring to the project, and confirm in writing what happens to code developed with award money.

How SBIR Funding Works for Software Startups at the Award Stage

Three distinct moments get confused in most accounts of the process: proposal selection, negotiation, and a fully executed award. Each one is real, and each one is a different state of funding.

Selection is a decision that your proposal was among those chosen. Nothing is committed yet, and agencies frequently select more proposals than they can fund at first, holding a ranked list. If your name appears on a selection list but not on the award, that is what happened.

Negotiation is where scope and budget get adjusted to fit the agency’s actual funding and program priorities. This is normal, and it is not a sign of failure. Teams who treat the first number they asked for as non-negotiable often negotiate themselves into a smaller award.

Executed award is the Notice of Award signed and the funds obligated. Only here is the money authorized, and only here should you plan your hiring, your cloud spend, and your subcontractor commitments.

The gap between a selection notice and an executed award is where multi-month delays live. Budget for a runway that does not depend on SBIR money arriving on a specific date.

What Can SBIR Funds Be Used For?

The approved budget and the award terms control, not your preferences. In practice, a software Phase I budget is almost entirely labor plus cloud and tooling.

• Direct labor and fringe for the company employees working on the project, including the PI.
• Cloud services, compute, storage, and datasets needed to run the experiments.
• Software tools and licenses used in development and testing.
• Contractors and consultants for work you cannot do yourself, including specialized review or security testing.
• Subcontracts to universities or labs where you need specialized facilities or expertise.
• Testing, prototyping, and limited equipment where the R&D requires it. Software proposals rarely have a big equipment line.
• Travel when the solicitation permits it, usually tied to a specific milestone.
• Indirect costs only at the rate the agency allows, if any. Many programs cap or exclude them.

What does not fit: sales and marketing, routine maintenance, features for existing paying customers, general business overhead not in the negotiated budget, and anything outside the statement of work. A $200,000 Phase I for a three-person software team is usually 70 to 80 percent labor, with the rest spread thin across cloud, tools, and a little testing. Lean heavily on labor and you will look like a software project, which is exactly what you want to look like.

No repayment is owed. SBIR is not a loan, not deferred equity, and not a royalty obligation. If someone tells you they will convert your SBIR award into equity, that is a private arrangement between them and the award, not how the program works.

What Compliance Rules Must Software Startups Follow?

Compliance is where small teams underestimate the load, and it is much lighter than most people fear if you start on day one.

The core obligations cover:

• Financial reporting. Periodic financial status and final reports tied to the budget lines you were approved for.
• Time and effort records. Charged labor has to be traceable to tasks. Keep timesheets from the first week.
• Procurement responsibility. Follow the agency’s rules for competition, justification, and property. This matters most if you buy significant equipment or use large subcontractors.
• Data handling and cybersecurity. Especially where your project touches agency systems, controlled unclassified information, or personally identifiable data.
• Export controls. Software with encryption, or any dual-use technical capability, may fall under export administration rules that limit who can receive the work.
• Security and specialty requirements. Some topics require cleared personnel, secure development environments, or a documented security plan before any work starts.
• Foreign participation limits. Payments to foreign entities, or work performed abroad, can be limited or prohibited entirely.

Program officers are the fastest way to get these questions resolved, and FAST offices exist to give free guidance to small companies. For anything involving IP terms, export control, or a foreign founder structure, get real legal and accounting advice. Rules and participating agencies change, so verify the current requirements against the solicitation you are actually answering.

What Are the Main Risks and Limitations?

Competition is the headline risk. Funded rates commonly land in the single digits to low double digits depending on agency and topic, and specific topics can be far more selective than the program average. Plan two submissions per cycle rather than one.

Fixed scope cuts both ways. You agree to deliverables for a fixed amount. Under-budgeting an experiment you hoped would be cheap is a real way to lose money on a win.

Payment timing is not the same as award timing. Awards can be delayed, reimbursement systems can slow cash, and in some cases you front costs.

Cost sharing applies in places. Some programs require a cost share, which reduces the award to fund it.

Agency dependence is real. The program officer relationship, the topic, and the budget are the company’s external environment. A change in agency priorities can end a line of work.

Phase III is not a contract. Having a completed SBIR award does not obligate an agency to buy anything from you. It gives you authority and a track record that help in a competition, which is still a competition.

It does not produce product-market fit. SBIR pays for answering a technical question. Whether anyone outside the government wants to buy what you built is a separate problem, and plenty of funded projects answer the technical question and still find no paying customers. Treating a grant as a demand signal is the most expensive misunderstanding in the program.

On funding status: SBIR authority is periodically reauthorized, and when it lapses agencies keep operating under extensions while new solicitations can be paused or delayed. If you are planning around SBIR money in 2026, check the current posting on sbir.gov first rather than trusting a blog post, including this one.

How to Prepare a Strong SBIR Proposal

Strong proposals are made, not inspired. The sequence below is the one that works for software teams.

1. Pick the topic, not the agency. Start from your technology and find the topic it answers. Teams that start from “we want DOD money” spend weeks writing about topics they do not fit.
2. Read the full solicitation twice. The instructions define what is judged. Missing a required section loses points before merit is even discussed.
3. Write one sentence of technical uncertainty. If you cannot state what is unknown and what experiment resolves it, you do not have an R&D project yet.
4. Frame the deliverable as a test. A prototype plus the data that says whether the approach holds up. A demo for its own sake is not research.
5. Define measurable milestones. Each milestone should have an objective test: accuracy on a held-out set, latency under a defined threshold, detection rate on a defined benchmark.
6. Build the commercialization path. Named customer segments, the federal offices that buy in that space, and what evidence you would gather in Phase I to prove they would.
7. Get letters of support early. From real users, integrators, or agencies. They cost little and they separate you from the stack of proposals with no external validation.
8. Assign roles and dates. A proposal is months of founder and technical time. If you are running it alongside other agency applications, founder time is your real constraint.

One last note on tooling rules. Some agencies, NIH in particular, restrict reviewers’ use of AI and restrict applicants’ use of it for idea generation and for writing substantial portions of the application. Read the current policy rather than assuming your tools are fine.

Frequently Asked Questions

What to Do First

Confirm eligibility in an afternoon: entity type, size standard, U.S. control, and whether your Principal Investigator’s primary job is with the company. If any of that fails, fix it before you spend a single week on a proposal.

Then pick one technology you actually want to test, find the open topic solicitation that matches it, and read the instructions end to end. Before committing the team’s time, talk to the program office named in the solicitation. A twenty-minute conversation usually saves three weeks of writing toward the wrong outcome.

Treat SBIR as one rung on the funding ladder rather than the whole ladder. Non-dilutive R&D money buys you a prototype, a credible past-performance record, and a door into agencies you could not otherwise reach. It does not buy you customers, and it works best when paired with a commercial plan you were going to execute anyway.