It's been a while (15+ years) since I was in that game... but back then, it was $60k for a Phase I and $200k for a Phase II. Phase III and beyond was open-ended.
You don't really make money on Phase I projects, but that's how you get the ball rolling on future work, which can be very lucrative.
I used to work for a company (~50 people) whose entire business was based on the SBIR pipeline. We did a lot of super-interesting work!
Here's my advice:
1) Your proposal needs to be completely solid and well-structured:
- Describe the problem. Put it into a Defense/Intel context. Talk about the needs of the warfighter.
- Do a literature review of the field, and explain what the state-of-the-art looks like today.
- Explain what previous approaches to the problem have been attempted in the past.
- Demonstrate why those approaches are flawed.
- Describe your novel approach.
- Explain why your approach will succeed where others have failed.
- Talk about what you'll deliver in your Phase I deliverable, so that you can demonstrate proof-of-concept.
- Talk about how your eventual Phase II will put your proof-of-concept into a real-world scenario, and offer at least a glimpse of how your Phase III+ will commercialize.
- Talk about your team. Why are you uniquely capable of solving this problem?
- Talk about your budget. How will you spend the money toward satisfaction of the deliverables (salaries, subcontractors, equipment and supplies, etc)
2) As soon as you know you're interested in a topic, send an email to the Principal Investigator, telling them you'd like to meet with them to talk about the topic. Before the phone call, research the PI's history with this topic. Also, lookup the archive of SBIR topics, to see if this person has been a PI on similar topics in the past.
When you meet with them, ask clarifying questions that demonstrate you know the domain. Try to get as much specificity as you can... Ask them what their success criteria look like. See if you can get them excited!
Most importantly, by the time you submit, the PI should already know your name and to expect your submission.
3) If you're not already a recognized expert, with published academic papers on the topic, that's okay! But you'll improve your chances of winning a grant if you hire a known researcher as an advisor. For example, I've hired a Computer Science professor to supervise one of their own grad students, while doing paid work on a SBIR project. So the professor's credentials and the grad student's previous publications also became part of the SBIR proposal.
Apple's philosophy is that new APIs need some time to stabilize before they can be baked-in as a commitment to third-party developers.
So new APIs are almost always first-party only. Apple designs the API and becomes the first consumer of it. This experience of dogfooding their own APIs lets them iterate and learn without breaking compatibility with third-party developers consuming the API.
Only after an API has been hardened in this way does it become eligible for third-party consumption, where Apple can promise to document and support those APIs publicly.
It makes sense then, that if the DMA mandates equal access to new APIs for third-parties, then Apple will just disable new first-party APIs in the region until they've gotten their bake-in period elsewhere in the world. Sorry, EU!
"Interoperability only works when it is built into the platform from the start"
-- Lucas Lasota, FSFE Legal Programme Manager
To my mind, this is almost exactly opposite of true. Most new capabilities need to be incubated in private first, so that the APIs can get real-world usage and have a chance to evolve into a stable state before they become public interoperability promises.
This is true, but I also think the input context isn't the only function of those tokens...
As those tokens flow through the QKV transforms, on 96 consecutive layers, they become the canvas where all the activations happen. Even in cases where it's possible to communicate some detail in the absolute minimum number of tokens, I think excess brevity can still limit the intelligence of the agent, because it starves their cognitive budget for solving the problem.
I always talk to my agents in highly precise language, but I let A LOT of my personality come through at the same time. I talk them like a really good teammate, who has a deep intuition for the problem and knows me personally well enough to talk with me in rich abstractions and metaphors, while still having an absolutely rock-solid command of the technical details.
But I do think this kind of caveman talk might be very handy in a lot of situations where the agent is doing simple obvious things and you just want to save tokens. Very cool!
I think the biggest injury to the hiring of junior devs happened after COVID made remote-work ubiquitous. It's a lot harder for a junior dev to get real mentorship, including the ambient kind of mentorship-by-osmosis, when everyone works alone in a sad dark room in their basement, rather than in an office with their peers and mentors.
The advent of agentic coding is probably punch #2 in the one-two punch against juniors, but it's an extension of a pattern that's been unfolding for probably 5+ years now.
You don't really make money on Phase I projects, but that's how you get the ball rolling on future work, which can be very lucrative.