A Phase I award is a small, time-boxed amount of money to retire one specific technical risk. Phase II is a much larger award that assumes you did.
The expensive failure sits between the two. The Phase I prototype works, it answers the question, the report is filed, and then Phase II begins with the team discovering that the prototype cannot be extended. The first months of a much larger award go to rebuilding what the first one already paid for.
That is a restart that looks like progress. This post is about the engineering decisions that prevent it. They are deliberately small, because Phase I budgets are small.
If you want the reviewer’s-eye version of this as a checklist, it is the architecture section of the Phase I to Phase II readiness worksheet. This is the build-side version: what to do in the first weeks so the checklist comes out well at the end.
Decide what survives before you write it
Most Phase I codebases are written under a deadline by someone whose actual expertise is the science. That is the right allocation of effort, and it produces prototype code. Nothing is wrong with that, provided you know which parts of it are prototype code.
On day one, write two lists:
- Meant to carry forward: the components Phase II will build on.
- Meant to be thrown away: the scaffolding that exists to get an answer.
The second list is not a confession. A throwaway notebook that produces the headline measurement is fine, as long as nobody mistakes it for the foundation. The danger is the third category, the code on neither list that quietly becomes the product because nobody decided otherwise.
For each item on the first list, write one line on why the Phase II requirements do not break it. If you cannot write the line, move the item to the second list. That is a cheaper discovery in week two than in month two of Phase II.
Design the data model against data you did not curate
The most common reason a Phase I system needs a rewrite is a schema that fits the one dataset used for the demo.
A curated dataset is clean in ways real data is not. Fields are always present, units are consistent, there is one source, and the volume fits in memory. A schema that emerged from that dataset encodes those assumptions, and every component built on the schema inherits them.
You do not need the real data to avoid this. You need one dataset nobody prepared for you, run through the pipeline early:
- A second source, even a small one, with a different shape.
- Data with missing fields, inconsistent units, and the failures real collection produces.
- Something larger than the demo, even if only enough to see where it stops fitting.
Document what breaks. A schema that has been wrong once, on purpose and early, is much safer than one that has only ever seen the happy path. It also gives you something concrete for the technical sections of a Phase II proposal, because “we tested against uncurated data and here is what it changed” is evidence rather than assertion.
Keep parameters out of the code
Hardcoded parameters are the quiet version of the same problem. A threshold tuned to the demo, a path to one lab’s file layout, a constant that happens to be right for one instrument: each is invisible until a second user, instrument, or site arrives.
The fix is unglamorous. Anything that a second deployment could plausibly set differently goes in configuration, with a default. It costs a few hours in Phase I and it is the difference between “extend it” and “rewrite it” when the second site appears.
Make the headline result runnable from the repository
A result that exists as a sequence of notebook cells and manual steps held in one person’s head is not reproducible, even by the person who produced it, six months later.
The standard to aim for is modest: a committed, runnable path from raw input to the number in the report, with the environment pinned. Not because a reviewer will run it, but because a result that cannot be reproduced internally almost always depends on a manual step nobody wrote down. Those steps are where Phase II schedules slip, because the work they hide is discovered at the worst time, under delivery pressure.
This is also the cheapest of the six to do, since it is mostly a matter of not skipping it as you go.
Capture evidence while you work, not after
The project outcomes report is a summary. It is much easier to write when the records already exist than when the work has to be reconstructed.
Instrument as you go: results, decisions, and the measurements behind them, saved as artifacts at the time. Keep the approaches that were tried and abandoned, with the measurement that ended each one. A well-characterised negative result retires risk just as genuinely as a positive one, and it is one of the best signals that the work was real. It also tells the Phase II design what not to repeat.
The cost during the build is close to nothing. The cost of not doing it is a report assembled from memory.
Draw the regulated-data boundary now
If Phase II is likely to involve patient data, human-subjects data, or anything export-controlled, and Phase I did not, you have a boundary problem waiting.
Regulated data entering a stack designed without it is not a feature to add. It is a line that has to be drawn through the architecture: where such data may live, who may touch it, what gets logged, which vendors may see it. Drawn under a Phase II delivery schedule, that work competes with the milestones the award is paying for.
Drawn in Phase I, it can be a one-page diagram. Nothing regulated has to arrive yet. The point is that the Phase II budget can reflect it, and that the Phase I architecture does not have a hole where the boundary needs to go. For health data specifically, the HIPAA architecture checklist lists the decisions in the order they come up.
What to ask a technical advisor
If you are considering outside engineering help on a Phase I, the useful questions are structural:
- Which components of what you are building are meant to survive into Phase II, and can they say why?
- What was the data model tested against, other than the demo dataset?
- Can the headline result be reproduced from the repository today?
- Where does regulated data go if it arrives?
An advisor who answers these specifically is worth more than one who offers to build faster. Speed is rarely the constraint on a Phase I. A prototype that answers the question and then has to be discarded is.
Program rules vary by agency and solicitation, including how much work may be performed outside the small business and how consultant costs must be budgeted. This post is about engineering, not eligibility. Confirm the rules in your own solicitation and with your grants officer.
I was principal investigator on NSF SBIR Phase I award #1941226 at Preventa Medical Corporation, where I wrote the work plan, ran the project, and filed the outcomes report. My lane is software. If you are scoping a Phase I build, or deciding what survives into Phase II, the fractional CTO engagement for SBIR-funded teams is built for it, and the free 30-minute call is the place to start.