SBIR Phase I to Phase II: What Actually Earned the Halovax Transition
Most Phase I winners never win Phase II. Here is the engineering evidence that carried the HaloVax vaccine delivery platform across, from a firm that ran the lab work.
August 22, 20267 min read
Written by Konstantin Dolgan, Ph.D., NPDP
Founder & CEO, Product Development Engineer
Published August 22, 2026
No, not all SBIR Phase I winners apply for Phase II, and far fewer win one. A Phase I award buys you a chance to produce evidence. The Phase II decision turns on whether that evidence exists in a form a reviewer can check. On HaloVax, a materials-enabled vaccine delivery platform, that evidence was lab data, working fixtures and a technical record built during Phase I rather than written after it.
Why most Phase I awards stop there
Phase I is short, small and technically narrow by design. It funds a feasibility answer, not a product. Teams fall out of the Phase II pipeline for a handful of repeatable reasons, and almost none of them are about the science being wrong.
Why a Phase I team does not reach Phase II | What it looks like in practice | What prevents it |
|---|---|---|
No citable data | The prototype worked in the room but nothing was instrumented, so the report reads as a description | Decide the measurements before the build, and design the fixture that produces them |
The claim moved | The Phase I result is real but answers a different question than the proposal asked | Freeze the technical claim in writing at kickoff and log every deviation |
No time to write | The Phase II window opens while the hardware is still on the bench | Schedule the proposal as a project milestone, not as an afterthought |
The team dispersed | Contract engineers rotate off and the technical context leaves with them | Keep one partner across phases so nothing is re-derived |
Commercial story missing | Strong technical work, no credible path to a customer or a manufacturable unit | Start the manufacturing and cost view in Phase I, even roughly |
The Halovax problem: delivery, not the vaccine
Modern vaccines fail in the field for reasons that have nothing to do with antigen selection: stability, dosing efficiency, controlled release, cold-chain dependence and plain operational handling. In defense, biodefense and global health settings, those logistics decide whether a dose ever reaches an arm.
HaloVax was conceived by Grapheno as a materials-enabled delivery platform designed for sustained, controlled release and for robustness in demanding environments.
Grapheno brought us in during proposal formulation, before any award existed. What they needed was not more biology. It was proof that the platform could be engineered, tested and eventually scaled, expressed in a way SBIR reviewers could evaluate as executable. That work is described in full in the HaloVax case study.
Deliverables produced during Phase I
- Engineering support for material handling and formulation concepts, so the carrier chemistry had a physical embodiment someone could build.
- Materials science work on carrier systems, loading strategies and controlled release behaviour.
- Custom lab setups and experimental fixtures, designed and built specifically to make the feasibility question measurable.
- Hands-on laboratory work generating the validation results that Phase I milestones required.
- A running technical record tying each result back to the milestone it satisfied.
The fixtures deserve their own line. A general-purpose lab can run a general-purpose test; a platform claim usually needs a rig that does not exist yet. Building that rig is engineering work, it consumes real Phase I budget, and skipping it is how teams arrive at the Phase II deadline with anecdotes instead of curves.
The questions a Phase II reviewer checks
Reviewer question | Weak answer | Answer built during Phase I |
|---|---|---|
Did the core claim hold? | We believe the approach is viable | Measured release behaviour against the stated target, with method and fixture described |
Can this team execute? | Our team has decades of experience | Phase I milestones met on schedule, with the deliverables listed and dated |
Is the next phase realistic? | We will scale the platform | A work plan naming the next unknowns, the tests that retire them and what they cost |
Will it ever be made? | Manufacturing will be addressed later | An early view of process, materials supply and unit cost, even at rough resolution |
Is the risk understood? | Risks are low | A named list of failure modes with the evidence that each was probed |
Completing Phase I successfully showed that HaloVax was viable, scalable and worth continued investment, and that execution record directly supported the Phase II award. The point worth carrying away is that the record was a deliberate output of Phase I, not a summary written at the end of it.
A pre-Phase II readiness checklist
- The technical claim is written in one sentence and has not silently changed since the proposal.
- Every milestone has a dated artifact behind it: a data file, a photo, a drawing or a report page.
- At least one result is presentable as a chart a stranger can read without a briefing.
- Failure modes found during Phase I are documented, including the ones you designed around.
- The Phase II work plan names the specific unknowns that remain, not a general intention to develop.
- Someone has looked at how the thing would be made and roughly what it would cost.
- The proposal has a calendar slot and an owner, booked before the hardware is finished.
One thing we would change
Instrument earlier. On interdisciplinary platforms the temptation is to get the chemistry behaving first and worry about measurement afterwards, which compresses all the data generation into the final weeks. Building the measurement fixture in parallel with the first formulation work costs a little more up front and buys weeks of usable data at the end, which is exactly the material a Phase II proposal is made of.
Teams planning this sequence deliberately can see how we scope it on our SBIR product development and prototyping page.
A Phase I calendar that leaves room to write
The single most common reason a strong Phase I never becomes a Phase II proposal is arithmetic: the last experiment finishes the week the proposal is due. Here is how we lay out a nine-month Phase I on hardware or materials work so the writing window exists before anyone needs it.
Window | Engineering focus | Proposal artifact produced |
|---|---|---|
Months 1-2 | Freeze the technical claim; design the measurement, not just the device | One-sentence claim, test plan, milestone map |
Months 2-4 | Build the fixture and the first article in parallel | Photographs, fixture drawings, first baseline data |
Months 4-6 | Run the core experiment; find the failure modes deliberately | Charts against the claim, a documented failure list |
Months 6-7 | Repeat the result; confirm it is not a one-off | Repeatability data, method write-up |
Month 7 | Rough manufacturability and cost read | Process notes, early BOM, cost sketch |
Months 8-9 | Write, with the bench quiet | Phase II technical volume and work plan |
Mistakes we have watched cost teams a Phase II
- Spending the fixture budget on a nicer prototype. The prototype impresses in a demo; the fixture produces the data the proposal is scored on.
- Running only successful tests. A reviewer reading a report with no failures assumes the envelope was never probed.
- Letting the claim drift. If the Phase I report answers a slightly different question than the proposal asked, the transition argument has a hole in it.
- Treating photographs as optional. Undocumented hardware effectively did not exist once the award closes.
- Outsourcing the writing to someone who never saw the bench. The technical volume reads generic and the specifics that would have scored are missing.
- Ignoring manufacturability entirely, then claiming a commercialization path in Phase II with nothing behind it.
What an engineering partner adds in the last six weeks
On HaloVax our involvement did not stop when the lab work produced numbers. The final stretch of a Phase I is largely a translation problem: turning bench reality into statements a reviewer outside your discipline can evaluate.
Practically that means redrawing test setups as clean diagrams, replotting raw data against the stated target rather than against instrument units, listing what was tried and rejected, and writing the Phase II work plan as engineering tasks with durations rather than as research aspirations.
It is also the moment to be honest about what is still unknown. A Phase II plan that names three specific unknowns and the tests that retire them reads far stronger than one that implies everything is already solved — because if everything were solved, there would be nothing left to fund.
The Phase I hand-off package we actually deliver
At the end of a Phase I engineering engagement the client does not need a folder of pretty renders. They need artifacts a proposal writer can lift into a Phase II narrative without re-interpreting them. This is the package we hand over, and roughly what each piece is worth once the writing starts.
Artifact | What is in it | Where it lands in a Phase II proposal |
|---|---|---|
Test log with raw data | Every run, including the failed ones, with fixture photos and date stamps | Technical objectives and the feasibility argument |
Requirements matrix | Each Phase I claim mapped to the measurement that supports or kills it | Work plan, showing what is settled and what Phase II resolves |
Design change log | What changed after each test round and why | Risk section, showing the team responds to evidence |
CAD and drawing set | Released geometry, tolerances and material callouts | Prototype plan and vendor quoting |
Fixture and rig documentation | How results can be reproduced by a third party | Reviewer confidence in the numbers |
Cost and lead-time notes | Quotes gathered during the build, with quantity breaks | Early commercialization and budget justification |
On HaloVax that package is what let the team move from feasibility into a funded development phase without re-running work.
If you are building the same evidence base now, our SBIR product development and prototyping support covers the engineering side, and rapid prototyping plus medical device prototyping cover the builds behind it.
Agency-side rules for what a Phase II must contain live with the programs themselves: Read more on Sbir, NIH SEED and NSF America's Seed Fund.
Frequently asked questions
Do all SBIR Phase I winners apply for Phase II?
No. A substantial share of Phase I awardees never submit a Phase II proposal, and agencies publish their own award counts by phase on sbir.gov . In our experience the deciding factor is rarely the science; it is whether the Phase I period produced citable technical evidence and whether anyone had time to write while the bench work was still running.
How long is the gap between SBIR Phase I and Phase II?
It depends on the agency and the solicitation cycle, and the funding gap between phases is a well-known planning problem for small businesses. Read the phase timing rules in the SBA program policy directive for your agency, then work backwards: the last useful test date is the one that still leaves time to analyse, plot and write.
What technical evidence does a Phase II proposal need?
Measured results against the claim made in Phase I, the method and apparatus that produced them, a record of milestones met, a named list of remaining unknowns with the tests that retire them, and an early read on manufacturability and cost. Narrative alone does not survive review.
Can an outside engineering firm work on an SBIR award?
Yes, within the subcontracting limits set for each phase by the SBA policy directive, which differ between SBIR and STTR and between phases. Confirm the percentage allowed in your specific solicitation before scoping outside work. On HaloVax we operated inside the program as the engineering and materials partner across proposal, Phase I execution and the Phase II transition.
How much of a Phase I budget should go to test fixtures?
On our projects it is commonly five to fifteen percent, and on measurement-heavy platform work it can be higher. Teams underspend here because a fixture is not a deliverable anyone celebrates. It is, however, the piece of hardware that converts a working prototype into citable data, which is what the Phase II decision runs on.
What happens if a Phase I result is negative?
A well-documented negative result is a legitimate Phase I outcome, and it is far better than an ambiguous one. Report the measurement, the conditions and the interpretation, then either propose the modified approach the data points to or say plainly that the path is closed. Reviewers penalise vagueness far more reliably than they penalise a bounded negative finding.
What should a Phase I final report include?
The measured result for every technical objective you set, the method and fixture used to get it, the design changes those results forced, and an honest statement of what remains unresolved. Reports that only report successes read as incomplete testing, not as strong work.
How early should Phase II planning start?
At the Phase I kickoff. The tests you plan in month one decide what evidence exists in month eight, and the proposal can only argue from evidence that already exists. Teams that start planning at the Phase I close spend their writing weeks discovering data gaps. Related reading: what a Direct to Phase II prototype has to prove , the commercialization plan reviewers believe , and our SBIR engineering support across every phase .
Related articles
All articles
The SBIR Commercialization Plan Reviewers Believe: Manufacturing Evidence, Not Market Size
Market slides do not make a commercialization plan credible. Manufacturing evidence does. How the AtmoSpark atmospheric water generator earned its production story.
Direct to Phase II: What the Grapheno-1 Prototype Had to Prove
Skipping Phase I means the prototype carries the whole feasibility argument. Here is how a field-deployable electrochemical crack repair system was engineered under a Direct to Phase II award.
Can your AI generated product actually be built?
← Back to blog LA NPDT / Editorial Blog / Manufacturability / 9 min read Can your AI generated productactually be built? Short answer: usually yes, but almost never as drawn. Her
Services related to this guide
- Product design servicesIndustrial design and CAD taken all the way to manufacturable files.
- Rapid prototypingWorking prototypes in days, from 3D printing to vacuum casting.
- Electronic design servicesSchematic, PCB layout, firmware and bring-up, through to production handoff.
- Product development examplesReal projects we designed, prototyped and shipped.