Reference · SBIR
Will Phase II extend your prototype, or restart it?
14 questions a Phase II reviewer effectively asks of a Phase I software deliverable. Most of them have answers that are free to change at month six and expensive to change at month eleven. Free, ungated, and useful whether or not you ever hire me.
Written by Eric P. Hassey, principal investigator on NSF SBIR Phase I award #1941226. Program mechanics differ by agency and change between solicitation cycles — confirm against your own award terms.
01
Did you retire the risk you said you would?
A Phase I deliverable is not a demo. It is evidence for one specific technical risk the proposal committed to retiring, assembled for a reviewer who will never run your code. The most common failure is a prototype that works and does not settle the question the award was funded to settle.
Can you state, in one sentence, the technical risk this award existed to retire — and point at the artifact that settles it?
Why it decides anything — Phase I is judged on whether the uncertainty is gone, not on how much was built. If the sentence and the artifact do not connect without explanation, the reviewer has to supply the connection themselves, and reviewers do not.
Signals trouble
A working prototype, a feature list, and a narrative that the technology is promising.
Holds up
One sentence naming the risk, one artifact demonstrating it, and a result a sceptical reader can check without trusting you.
Does every technical objective in the funded proposal map to something buildable that was actually built?
Why it decides anything — Objectives that read well in a proposal sometimes describe no testable artifact. That mismatch is cheap to find in month two and expensive at the annual report, because by then the mismatch is also a reporting problem.
Signals trouble
Objectives restated in the report in the same language as the proposal, without pointing at anything.
Holds up
A table mapping each objective to a specific artifact, result, or documented negative finding.
Do you have a defensible account of what did not work?
Why it decides anything — A Phase I that reports only successes reads either as unambitious or as incomplete. A well-characterised negative result retires risk just as genuinely as a positive one, and it is evidence that the work was real.
Signals trouble
Failures omitted, or described only as things still in progress.
Holds up
The approaches that were tried and abandoned, with the measurement that killed each one and what it implies for the Phase II design.
02
Does Phase II extend this, or restart it?
This is the question with the largest financial consequence on the list, and the one most often answered by accident. A Phase I prototype architected as a throwaway converts a funded head start into a standing restart — you spend the first months of a much larger award rebuilding what you already paid for.
Which parts of the Phase I codebase do you intend to keep, and does the architecture actually allow that?
Why it decides anything — Intent is not enough. Prototype code written under a Phase I deadline routinely bakes in single-tenancy, hardcoded parameters, or a data model shaped by one demo dataset. Any of those can make "extend it" mean "rewrite it" in practice.
Signals trouble
An assumption that the code carries forward, untested against the Phase II scope.
Holds up
A named list of components to keep, and for each one a specific reason the Phase II requirements do not break it.
Was the data model designed around your demo dataset or around the data you will actually have?
Why it decides anything — This is the single most common source of Phase II rewrites. A schema that fits the one curated dataset used for the prototype tends to fail on the volume, messiness, or multi-source reality of the real deployment — and schema changes propagate through everything built on top.
Signals trouble
A schema that emerged from the prototype and has never seen data from a second source.
Holds up
A model tested against at least one dataset nobody curated for you, with the failures documented.
If the Phase II proposal claims scale, does anything in Phase I support the claim?
Why it decides anything — Proposals routinely promise throughput, accuracy, or concurrency numbers that the Phase I artifact was never instrumented to measure. Reviewers who know the domain notice when a number appears with no measurement behind it.
Signals trouble
Projected figures derived from the architecture on paper.
Holds up
A measurement at small scale, an explicit model of how it extrapolates, and a stated point where the approach would have to change.
Will regulated data arrive in Phase II that Phase I was never scoped for?
Why it decides anything — PHI, human-subjects data, or export-controlled material entering a stack that was designed without them is not a feature addition — it is a boundary that has to be drawn through the architecture. Discovering this after the Phase II award means designing it under a delivery schedule.
Signals trouble
An expectation that compliance is addressed later, or that the cloud provider handles it.
Holds up
The boundary drawn now, even if nothing regulated has arrived yet, so the Phase II budget reflects it.
03
Is the evidence reproducible?
Reviewers weigh evidence, and evidence assembled after the fact is always thinner than evidence captured as you go. This is also where the reporting obligation stops being paperwork and becomes instrumentation.
Could someone else reproduce your headline result from what is in the repository today?
Why it decides anything — Not because a reviewer will try, but because a result that cannot be reproduced internally tends to be a result that quietly depends on a manual step nobody wrote down. Those steps are where Phase II schedules go to die.
Signals trouble
A result produced by a sequence of notebook cells and manual steps held in one person's head.
Holds up
A committed, runnable path from raw input to the reported number, with the environment pinned.
Does the project outcomes report write itself from artifacts you already have?
Why it decides anything — If assembling the report means reconstructing what happened, the reconstruction is what gets reported. Instrumenting as you go costs almost nothing during the build and makes the report a summary of records rather than a memory exercise.
Signals trouble
The report started after the technical work ended.
Holds up
Results, decisions, and measurements captured as artifacts during the work, with the report drawing on them.
Do you know where every dataset came from and what you are permitted to do with it?
Why it decides anything — Data acquired informally during Phase I — scraped, shared by a collaborator, licensed for research use — can turn out to be unusable in a commercial Phase II. That discovery invalidates results built on it, which is worse than not having had the data.
Signals trouble
Datasets in the repository with no recorded source or terms.
Holds up
Provenance and usage terms recorded per dataset, and any research-only data identified before Phase II depends on it.
04
Does the software support the commercial story?
Phase II review weighs commercial potential alongside technical merit, and the commercialisation claims in a proposal frequently describe a product the software cannot yet be. This is not a marketing problem; it is a scoping one.
Do the commercialisation claims describe something the current architecture could become, on the Phase II budget?
Why it decides anything — A claim about integrating with customer systems, serving multiple organisations, or meeting an industry standard is an architectural commitment. Made in a proposal and discovered in the build, it consumes budget that was allocated to the technical objectives.
Signals trouble
Commercial narrative written independently of the engineering plan.
Holds up
Each commercial claim traced to the work item that makes it true, with that item in the budget.
Has anyone outside the project used the thing?
Why it decides anything — A letter of support is a statement of interest. Someone who has actually run the software and reported back is evidence, and it is the kind that distinguishes a Phase II application from its neighbours.
Signals trouble
Support letters and expressions of interest only.
Holds up
At least one external user, what they did, and what came back — including what they could not do.
05
Have you used the money that already exists?
Two funding mechanics decide whether outside technical help is even payable, and both are frequently discovered too late to use. Details vary by agency and solicitation — confirm against your own award terms rather than this page.
Have you claimed your technical assistance allowance?
Why it decides anything — SBIR and STTR awards carry a technical and business assistance allowance outside the main budget — commonly up to $6,500 at Phase I and up to $50,000 at Phase II. At NSF it is generally built into the proposal; NIH has allowed awardees to request it after the award by administrative supplement. Many awardees never claim it at all.
Signals trouble
Unaware of the allowance, or assuming the deadline to use it has passed.
Holds up
The allowance identified, its mechanism for your agency confirmed in writing, and a plan for what it buys.
If you want outside engineering help in Phase II, is it in the budget you are about to submit?
Why it decides anything — The small business generally must perform a minimum fraction of the work itself — at NSF, at least two-thirds by budget at Phase I — and consultant or subaward lines must be budgeted in the proposal. A need discovered mid-award usually cannot be funded, which is why this belongs on a pre-submission checklist rather than a post-award one.
Signals trouble
Intending to find engineering help once the award lands.
Holds up
The consultant or subaward line written into the proposal, with the named person and the justification for why the work requires them.
I add to this as Phase II reviews come back
The checkpoints that get added are the ones that were not obvious until a proposal came back with a comment about them. Leave an email and you get them when they land — nothing else, no sequence, no pitch.
Questions PIs ask
When should a Phase I awardee work through this? +
Around month six, when the Phase II proposal starts getting written and there is still time to change the answer. Working through it in the final weeks of Phase I turns it into an inventory of things that cannot be fixed, which is useful but much less valuable.
Can SBIR funds pay an outside engineer? +
Generally yes, within limits, and only if it was budgeted in the proposal. The small business is normally required to perform a minimum share of the work itself — at NSF, at least two-thirds by budget at Phase I — and consultant or subaward lines have to appear in the submitted budget. This is why the question belongs on a pre-submission list: a need discovered mid-award usually cannot be funded from that award.
What is the technical assistance allowance, and can it still be claimed? +
SBIR and STTR awards carry an allowance for outside technical and business assistance that sits outside the main budget — commonly up to $6,500 at Phase I and up to $50,000 at Phase II. At NSF it is generally built into the proposal. NIH has allowed awardees to request it after the award through an administrative supplement. Mechanisms differ by agency and change between solicitation cycles, so confirm against your own award terms and your program officer rather than this page.
We have not submitted yet. Is this still the right list? +
It is the better time to use it. Roughly half of these checkpoints are decisions that are free before submission and expensive afterwards — particularly the budget questions and the architectural ones. Reading the list while the technical volume is still a draft is the cheapest point at which any of it can change.
Who wrote this? +
Eric P. Hassey, who served as principal investigator on NSF SBIR Phase I award #1941226 at Preventa Medical Corporation — $249,251, awarded December 2019 and executed through April 2021 — where he wrote the work plan, ran the project, and filed the project outcomes report. The award record is public and linked below. His lane is software: architecture, data pipelines, and machine learning, rather than instrumentation.
Want someone to answer these with you?
The list is the easy part. The hard part is deciding which weak answers are worth fixing before the proposal goes in and which are worth writing honestly into the risk section instead. That is the conversation.