Why Strong Technical Teams Lose SBIR Phase II on a Technicality

The worst SBIR losses are preventable. A team with real technology, a real customer, and a real shot writes a proposal that never gets a fair technical read because something mechanical or tonal knocked it out first.

The enemy is not your competition. It is a tired reviewer on proposal 37 of 40, looking for a reason to move you to the no pile. Mechanical and tonal mistakes hand it to them. Strong teams lose in two boring ways. Neither needs better technology to fix. Both need knowing they exist.

Bucket one: the compliance failures

Some of these are fatal on their own: over the page limit, a required form missing. The proposal dies before a technical reviewer sees it. Others are credibility damage that poisons the read rather than auto-rejecting you: an undefined acronym, a placeholder left in. You cannot tell from the outside which reviewer is in which mood, so treat every one as a hard submission blocker.

• Over the page limit. Pages beyond the limit are not evaluated. Your conclusion was on page 16. It was not read.
• A required form missing. The DD form, the cybersecurity self-assessment upload, the certification. Administrative rejection.
• Font below the floor. Shrinking the body font to fit is the oldest mistake and it gets the document rejected unread.
• An undefined acronym. An undefined acronym on page two tells the reviewer you did not run a basic pass. Credibility damage, not auto-reject, but treat it as a blocker.
• A placeholder still in the document. "TBD," a bracketed role, a fill-in left in. This signals an unfinished proposal, which is exactly what it is.
• Incomplete foreign-national disclosure. The work must be performed in the United States and any foreign nationals disclosed; an incomplete disclosure is a compliance failure, not a paperwork nit.
• An abstract over its character limit. The portal truncates it mid-sentence and that is the first thing the reviewer reads.

Every one of these is avoidable in the last hour before submission, if you have a list and run it. That is the entire reason a disqualifier pre-flight exists.

Bucket two: the narrative disqualifiers

These do not bounce the proposal automatically. They do something worse: they make a reviewer who was on your side stop being on your side.

• "We already built it." The fatal framing. The reviewer's job is to fund R&D. If the work is done, why fund it? Show the proven foundation, then the new build. Always.
• Telling the reviewer how to read the proposal. "Phase II does not fund discovery, it funds X." "What this actually buys is." This is the clearest signature of a first-timer. Describe the work. Let the milestones speak.
• Naming competitors or brand-name tools. It invites a comparison fight you do not need and locks you to a vendor. Describe the capability, not the brand.
• Quoting the government's pain back at them, repeatedly. Once, in the opening, with a date and attribution: credible. Three times, paraphrased: contempt.
• A cross-subsidy cost story. "Our overhead is low because other contracts cover it." That is a cost-allowability red flag. "Our overhead is low because we are a lean founder-run team" is a story. Same number, opposite reception.
• Commercialization as an agency list. Opening with "we will also sell to the Army, Navy, Air Force, DARPA, and DIU" reads, to the sponsor funding you, as their dollars buying someone else's benefit. Lead with a concrete market.
• A dev or staging URL in the document. It says the thing is not real yet.
• Pre-conceding data rights to look generous. A rights concession cannot be a condition of award and any expanded license is voluntary post-award. Giving rights away in the proposal only weakens you, and you cannot be required to.

Why this keeps happening to good teams

Because the people writing these proposals are engineers and founders, not proposal professionals, and the failures above are invisible from inside the work. You are deep in the technical merit. You cannot see that page 16 will not be read or that "Phase II does not fund" reads as amateur, because you are not reading it the way a tired reviewer with forty proposals will.

The fix is not "be more careful." The fix is a checklist that does not depend on you remembering, run every time, mechanically.

The pre-flight

Before you submit, top to bottom, no exceptions:

• Rendered PDF page count within the limit
• Declared body font at or above the floor
• Every acronym defined on first use
• Zero placeholders or "TBD"
• A dollar amount and an acceptance line on every milestone; sum hits the ceiling
• Foreign-national disclosure complete; US-performed stated
• Every abstract within its character limit
• No dev URL, no competitor or brand name, no "what this actually buys" sentence
• Commercialization leads with a market, not an agency list
• Data rights asserted, not pre-conceded

We made this concrete: a free Reviewer Scorecard and an open-source linter that enforces the countable rules deterministically. Run it on a draft and it tells you which of these you just did, before a reviewer does.

This does not make a weak proposal win. It stops a strong one from losing for a reason that has nothing to do with the merit of your work. Do this now: run the open-source linter on your draft. It tells you which of these you just did, before a reviewer does. Back to the main playbook.