Founders building software assume SBIR is for people with test benches and machine shops. It is not. Every participating agency funds software — algorithms, simulation tools, cybersecurity, clinical decision support, autonomy stacks, data platforms. What trips software companies up is not eligibility but the research bar.
SBIR stands for Small Business Innovation Research, and the middle word does the work. Building a well-engineered SaaS application using known techniques is product development, however hard and however valuable. It is not research, and a proposal describing it will be scored as having no innovation.
The line reviewers are drawing
The question a reviewer asks is: what here might not work?
If the answer is "nothing, technically — it is a matter of engineering effort," you have described a product, and the correct funding source is customers or investors. If the answer names a genuine technical uncertainty — an algorithm that may not converge, a model that may not generalize, a performance target nobody has hit on the available hardware — you have a research question, and that is fundable.
| Reads as product development | Reads as research |
|---|---|
| Build a mobile app and web dashboard for equipment operators | Determine whether a compressed model can detect the failure mode on-device within a bounded latency budget |
| Integrate our platform with three EHR systems | Develop and validate a method for reconciling conflicting clinical records without manual review |
| Add multi-tenant support and role-based access control | Establish whether a privacy-preserving computation approach retains sufficient analytical accuracy on real data |
| Rebuild the front end in a modern framework | Characterize the accuracy limits of a proposed sensor-fusion approach under degraded input |
Notice that the right-hand column has measurable pass/fail outcomes. That is not a coincidence — it is what makes a feasibility study a feasibility study.
Where software fits best by agency
Software has good homes across the program, but the fit differs sharply:
- NSF is the most software-friendly of the investigator-initiated agencies: deep technology broadly, no topic to answer, so a novel algorithmic approach with a commercial story fits directly.
- NIH funds health software heavily — decision support, imaging analysis, digital therapeutics, research informatics. Expect clinicians on the panel and questions about clinical ground truth.
- DoD publishes enormous numbers of software topics: autonomy, sensor processing, cybersecurity, modeling and simulation, logistics. Topic match is everything.
- DOE, NASA, DOT, DHS fund software tied to their missions — grid modeling, flight software, traffic systems, screening algorithms.
Which to target depends on your eventual customer, whether the agency uses contracts or grants, and how the review culture matches your evidence. For clinical software, NIH grants for medical device startups covers that path, and SBIR Phase I versus Phase II is worth reading before you scope anything.
Framing a Phase I for a software product
A Phase I is a feasibility study, usually six to twelve months and somewhere between $50,000 and $300,000 depending on agency. The deliverable is an answer, not a shipped product.
- State one central technical question. One, not five. "Can approach X achieve Y accuracy on Z class of real-world data?"
- Define the success criterion numerically up front. Reviewers want a threshold they can hold you to, and so should you.
- Describe the data. Software feasibility lives or dies on data access. Say what data, from where, with what permission, and what happens if the source falls through.
- Build only the minimum software needed to answer the question. Reviewers do not object to ugly research code; they object to research money spent on polish.
- Say what a positive result unlocks — the bridge to Phase II and to revenue after it.
The task list should read as experiments with outcomes, not sprints with features. That reframing fixes most rejected software proposals.
The things software founders forget to address
Why a large incumbent has not already done this
Software has low capital barriers, which reviewers know. If your idea is good and easy, why has a well-funded platform company not shipped it? Good answers exist — a specialized dataset, a domain relationship, a genuinely novel technique, a market too small to interest a giant. State yours rather than hoping nobody asks.
Intellectual property
Software patentability is narrower than it once was, and reviewers and later investors both probe it. Your defensibility may rest on trade secrets, data assets, or execution — a legitimate position, but say so deliberately. See what software still qualifies for a US patent and who owns the IP from a federal grant, which covers government data rights in software deliverables. Check the solicitation's source-code terms; they vary by agency.
Regulatory status
If your product diagnoses, treats, or drives clinical decisions, it may meet the FDA's definition of a device, which changes timeline and budget substantially. The tests are in Software as a Medical Device, and getting this wrong in front of a panel that includes clinicians is a credibility problem.
The path to a real product
Reviewers know research code is not a product. Acknowledge the gap and cost it: security review, reliability, support, deployment. For a companion app, the realistic numbers are in what drives mobile app development cost. Naming those costs shows you understand the road past the award.
Hardware-plus-software is often the stronger application
If your software controls, analyzes, or extends a physical device, propose the system. Agencies fund embedded intelligence readily — edge inference, sensor fusion, closed-loop control — and the physical constraints supply exactly the technical uncertainty a pure software proposal lacks. "Can this model run within the power and latency budget of a battery-operated device?" is an unambiguous research question. It also sidesteps the "why hasn't a big platform built this" problem, because hardware integration is genuinely hard and genuinely defensible.
The realistic assessment
Software companies win SBIR awards every cycle. They win when the proposal identifies real technical risk, defines a measurable feasibility test, names a customer, and treats the award as research funding rather than a substitute for a seed round. They lose when it is a product roadmap with a grant application wrapped around it.
If nothing about your build is technically uncertain, SBIR is the wrong instrument and grants versus investors will point somewhere better — a useful conclusion to reach in an afternoon rather than after ten weeks of writing. Start with the basics in our SBIR grant application guide.
Projects House builds products where firmware, software, and hardware work as one system — exactly the territory where software proposals become strong. For help defining the technical risk and feasibility milestones behind an application, reach us through the contact form.