Hunter Rosenblume's GTM as Code talk is not about AI. It's about what happens when a founder decides that no existing software fits their sales motion — and builds the one that does, in 4.5 weeks, with no engineering team.
| Metric | Value |
|---|---|
| RFPs submitted before automation | 91/year |
| Team size before | 5 people |
| Team size after | 2 people |
| Build time (RFP Gremlin) | 4.5 weeks |
| Full platform build time | 90 days |
| Avg proposal length | 100+ pages |
| Contract value range | $3M–$30M |
| Contract duration | ~5 years |
| US school lunch market | ~$50B/year |
What to take away
- Build-vs-buy clarity comes from specificity. When RFP software didn't support photo-first proposals, Hunter built his own instead of compromising on the product. He knew what he needed too precisely to accept a generic tool.
- 4.5 weeks is the new 12 months. RFP Gremlin was built by Hunter and one partner, Sheila (CPO), in 4.5 weeks. The full internal platform — all apps, all tooling — took 90 days.
- Two people doing what five used to do. Before RFP Gremlin, five people worked late to submit 91 RFPs per year. After: two people, more volume, better-looking proposals.
- AI is best at structured extraction. School lunch RFPs have standardized fields: hot vs. cold lunch, Monday-through-Friday service, financial health of the district. Claude is excellent at pulling those from long documents accurately.
- The primitive insight. Hunter's advice: as you investigate what to build vs. buy, you'll find certain things are primitives. He called out Type.com as an example — a tool that solved a whole class of agent-chaining problems cleanly.
- Five-year contracts change your build calculus. Ordo holds customers for ~5 years on contracts worth $3M–$30M each. That makes investing in bespoke internal tooling obvious. Everything they build is long-term.
The context: $50B in school lunch, all gated by RFPs
Ordo is America's fastest-growing school lunch program. Hunter Rosenblume, the CEO, is a Thiel Fellow who grew the company to eight figures in revenue across 15+ states with 12 people.
That ratio — eight figures, 12 people — is the first thing that gets your attention.
The second is the GTM model. If you want to serve school lunch at a school district, you have to win a government RFP. These are not short documents. Every proposal Ordo submits is over 100 pages, custom-written for that district. Contracts are typically 5 years and range from $3M to $30M. There's roughly $50B in school lunch contracts bid annually in the US.
"Last year, we brute-forced our way to winning these. The team was up late hours. Five people working on this and we were able to submit 91 RFPs."
91 RFPs × 100+ pages each = brute force.
Why existing RFP software didn't work
Hunter and his CPO Sheila went shopping for RFP software before building. They looked at all the major platforms. The problem:
"All of them are very word and text based. They were very clinical."
For Ordo, that's a dealbreaker. School lunch is a food product. People need to see photos of the food. Not stock photos — 100% accurate photos of exactly what they'll serve.
"We're a school lunch company. We kind of have to show photos of the food. It's probably important."
No existing tool supported photo-first, visually designed proposals. So they built one.
What RFP Gremlin actually does
The tool takes an RFP from end to end:
Extraction layer: Ingests the RFP documents (often 50-100 pages of government specifications) and extracts structured fields specific to Ordo's needs. Does the district want hot or cold service? Monday-through-Friday or Monday-through-Thursday? What's their financial health? Is there a deficit that might make them prioritize lowest price?
These are not generic fields. They're Ordo-specific business logic baked into the extraction prompt.
Decision layer: That financial deficit example is telling. Hunter showed a screenshot where the tool flagged a district running a deficit — surfacing a signal about whether Ordo should bid at all, or how to position price if they do.
Proposal generation layer: A Microsoft Word-style interface with tabs and photo sections. Blue-highlighted text shows AI-extracted fields that were pulled from the RFP and inserted into structured templates. Each section can be saved for reuse — "Atlanta area schools" gets its own saved section, for instance.
The output looks like a designed document, not a government form.
The build philosophy that made this possible
Hunter was direct about what changed the calculus:
"RFP Gremlin was built by me and my partner Sheila. We did this by ourselves. The entire internal platform you just saw was built in the last 90 days."
Two people. No dedicated engineering team. The entire internal platform — apps, tooling, the factory that pushes and expands tickets — built in 90 days.
He connected this to a broader principle:
"What is the primitive of this technology? What do I want to spend my time doing? What do I not want to spend my time doing?"
That question — what's a primitive vs. what's something you build — is the actual framework. For Ordo, photo-first proposals were a requirement precise enough that no SaaS could satisfy it. So it became a build. For agent chaining and data querying, Type.com was precise enough to serve as a primitive. So that became a buy.
The clarity comes from specificity of the problem, not from a general rule about build vs. buy.
What makes Ordo an unusual case study
Hunter flagged this himself:
"I wouldn't be resemblant of it. How many school lunch companies do you know who are also up here talking about this stuff?"
Ordo is weird. They're not a SaaS company. Their GTM is entirely RFP-driven — no cold email, no LinkedIn ads. The sales motion is: tasting event to get warm, then compete on the required contract. You cannot skip the RFP; it's a legal requirement for the school district. So making RFP production faster is directly constraining revenue throughput.
That's what makes the build-vs-buy calculus so obvious for them, and potentially less obvious for other companies. But the underlying principle — find the friction in your specific sales motion and build the tool that removes it — applies anywhere.
What's next
With RFP Gremlin handling the proposal layer, Hunter's team has started building around it. A factory for pushing and expanding tickets. Apps for the full network — caterers, food suppliers, school administrators, regulators. He described some as still live, others as replaced by better primitives as they discovered them.
The pattern he described: build something, discover a better primitive in the ecosystem, swap it out. Keep moving.
What this means
If you run RFP-dependent sales (government contracts, B2B procurement, enterprise bids), RFP Gremlin's architecture maps directly: extraction layer (AI reads the RFP spec), decision layer (AI flags bid/no-bid signals), proposal generation layer (AI writes into a branded template). Hunter built this in 4.5 weeks without an engineering team.
If you're evaluating build vs. buy for internal tooling, Hunter's framework is the clearest one available: identify the thing generic SaaS can't do (for Ordo: photo-first proposals). That's your build. Everything else that other tools do well enough is a primitive — buy it and move on.
If you want to hire fewer people while handling more volume, this is the case study: two people now do what five did before, with better output. The constraint was proposal quality, not headcount.
Hunter Rosenblume on LinkedIn · @hrosenblume on X · hunterrosenblume.com · Ordo
Watch the full GTM as Code event · Nandika Jhunjhunwala on account scoring for GTM agents · Nick Lafferty on marketing engineering and AI search · Kathleen Booth on building competitive intelligence without engineers
Build the GTM tools your category actually needs
Deepline gives your Claude Code workflows direct access to 79 enrichment providers. When off-the-shelf RFP software doesn't fit your business, build the one that does.