Usually the PI’s graduate students build the research logic, and a campus research software group or an outside engineering team builds the parts that must survive five years of real users. As a general range, plan 10–20% of a $400,000-plus CAREER award for professional engineering, with most of it spent in years one and two.
Who builds the software platform for an NSF CAREER award, and how?
Why a CAREER platform is a different software problem
A CAREER award is a five-year grant to one early-career PI, and the solicitation asks the research and education plans to be integrated. When the platform is the tool for both, such as a learning environment used in courses, a data-collection app for a field study, or an outreach tool for K–12 classrooms, the software has to last the whole award.
Five years is longer than most graduate students stay in a lab. The usual failure is not a bad first version; it is a working version nobody left in the lab can deploy, fix or extend in year four. How the platform gets built should be planned around that handoff.
Check the current CAREER solicitation on nsf.gov for the minimum award size and required plan sections. Your sponsored programs office will confirm how software costs can be budgeted at your institution.
The four ways it gets built
Most labs end up using a mix of these. The table compares them on what matters over a five-year award.
| Who builds it | Typical cost | Strength | Main risk |
|---|---|---|---|
| Graduate students in the lab | Stipend and tuition already in the budget | Knows the research question; builds fast | Graduates in year 3–5; code often has no tests, docs or deployment pipeline |
| Campus research software engineering (RSE) group | Internal recharge rate; varies by institution | Familiar with university IT, IRB and security review | Limited capacity; may not have a slot when your timeline needs one |
| Outside engineering firm | Fixed-price milestones or hourly, budgeted as consultant services or a subaward | Production discipline: testing, deployment, monitoring | Can own too much; needs a clear scope and a handoff plan |
| Hybrid: students plus engineering team | Smaller professional line, students cover research features | Students stay on research; the platform stays maintainable | Needs one person, usually the PI, to set priorities |
The hybrid is what we see work most often. Students write the research-specific parts: the task logic, the experimental conditions, the analysis scripts. The engineering team builds and owns the foundation: authentication, data storage, logging, deployment and the test suite.
How the build runs across five years
- Months 1–2: scope and architecture. Write down what the platform must do for each aim, who logs in, what data is collected, and which institutional reviews apply (IRB, campus security, and for minors, FERPA- and COPPA-aware design that your compliance office signs off).
- Months 2–6: first production release. Accounts and roles, the core task or activity, research-grade event logging, automated backups, a staging environment and one deployment pipeline. A focused 30-day sprint can produce a pilot-ready version of a narrow tool; a multi-role platform takes three to five months.
- Months 6–12: first pilot. Run it with real users, fix what breaks first (usually login on locked-down networks, slow connections and lost work), and freeze the logging schema before the main data collection starts.
- Years 2–5: maintain and extend. Dependency and security updates, new study conditions, and the education-plan features. Budget a small number of engineering hours every year rather than none.
One example of what this phase looks like: we stabilized an NSF-funded React/Firebase research platform used across several universities. We fixed state-driven audio lag, made saving and loading student work 100% reliable, and gave the distributed research groups one deployment pipeline. That kind of work is cheaper when it is planned in year one than when it is a rescue in year three.
Budgeting the engineering: a worked example
Take a $500,000 five-year CAREER award whose platform supports both a classroom study and a course-based education plan. Here is one way to budget outside engineering at our hourly rate of $85.
| Period | Work | Hours | Cost |
|---|---|---|---|
| Year 1 | Architecture, first production release, logging, deployment pipeline, pilot support | 400 | $34,000 |
| Year 2 | Main-study hardening, new conditions, data export for analysis | 120 | $10,200 |
| Years 3–5 | Updates, education-plan features, handoff documentation | 60 per year | $15,300 |
| Total | 700 | $59,500 (about 12% of the award) |
What moves the number: how many user roles there are (students, teachers, researchers), whether minors’ data is involved, whether the platform calls AI models, and how many sites it runs in. A single-role data-collection tool can come in under half of this; a multi-site platform with AI features can run higher.
Ask your sponsored programs office early whether to budget the work as consultant services or a subaward. The choice affects how indirect costs apply and what paperwork the vendor needs.
What reviewers and program officers look for
- A credible plan for the platform to exist in year five. Panels notice when a five-year education plan depends on software one student will build.
- Reliability treated as research validity. Lost sessions and inconsistent logging become missing data, and missing data weakens the study.
- A data management plan that matches the software. Say what is logged, where it is stored, how it is de-identified and how it will be shared. The plan should describe what the platform actually does.
- Proportion. A CAREER proposal is a research and education plan, not a software company pitch. Describe the platform as infrastructure for the aims, with a budget line that fits.
When the graduate student should keep building
Keep it in the lab when the tool is used only by your own group, collects no data about minors, runs for one study, and the student building it will be there for the whole study. Bring in an engineering team when outside users log in, when a school or partner institution must approve it, when data from the platform is your primary outcome measure, or when the builder graduates before the award ends.
Whoever builds it, the code should live in a repository the university controls, deploy from documented steps, and come with enough written documentation that the next student or engineer can take it over in a week.
Frequently asked questions
Can I put an outside software developer in my NSF CAREER budget?
Generally yes, as consultant services or as a subaward, if the work is needed for the project and justified in the budget justification. Your sponsored programs office decides which category fits and how indirect costs apply. Name the deliverables and hours, not just a dollar figure.
How much of a CAREER award should go to software?
As a general range, 10–20% of the award covers professional engineering for a platform that supports both research and education aims. A narrow single-study tool can need less. Put most of it in years one and two, and keep a small yearly line for maintenance.
Should my graduate student build the CAREER platform?
For research-specific logic, often yes. For the parts that must survive five years and outside users, such as authentication, data storage, logging and deployment, a professional team lowers the risk that the platform breaks when the student graduates. A hybrid of the two is common.
What happens to the platform when the CAREER award ends?
That depends on what you plan in year one. If the code lives in a university-controlled repository, deploys from documented steps and runs on infrastructure with predictable costs, it can continue under a follow-on grant or be handed to another lab. Without that, many platforms stop running when the hosting bill or the last student leaves.
Do I need IRB and FERPA review for a CAREER education platform?
If the platform collects data from human subjects, your IRB will review the study, and if it collects student education records, FERPA applies. Platforms used by children under 13 also raise COPPA questions. The software should be designed to support those requirements, but your institution’s IRB, counsel or compliance office makes the determination.
Planning the platform for a CAREER proposal?
We offer a free 30-minute review of the technical section of your proposal or your pilot plan. Bring the prototype’s repository or a demo, your timeline across the five years, and the parts of the solicitation the platform has to support. Start a conversation.