Building GrantBuddy: An AI Partner for Turning an Idea Into a Fundable Venture

This post was written as part of my submission to Google's All Things Agentic Hackathon.

A few days ago I set out to build an agent for the hackathon's "Collaborative Partner" track. The brief was simple to state and hard to do well: build something that guides a user step by step, asks clarifying questions, and adapts based on their feedback — rather than just another chat window with a system prompt bolted on.

I picked a problem I actually understand: most founders don't get stuck at the writing stage. They get stuck earlier — deciding whether an idea is worth pursuing, figuring out what money exists to try it, and building the confidence to put a case in front of someone. And they get almost no real feedback until they've already sunk hours into the wrong direction.

That's what GrantBuddy is: a venture-creation partner. You bring it a rough idea, and it takes you through five stages — matching you to real funding programmes, drafting a natural business case, auditing every claim in that case for whether it's actually grounded in evidence, and only handing you the final draft once you and the agent have both done the work to make it defensible.

The part everyone gets wrong: LLMs are confidently wrong about evidence

The single hardest problem in this project wasn't prompting — it was grounding. Ask an LLM to write a pitch for a pre-revenue business and it will cheerfully invent a market size, describe "proven customer traction" that doesn't exist, and generally write the confident version of the story instead of the true one.

So GrantBuddy doesn't have one agent writing the case — it has three doing different jobs:

- Scout matches the idea against funding programmes and flags eligibility gaps.

- Writer drafts the case, but tags every single claim as supported, assumption, or missing.

- Checker audits that draft, scores how well it's grounded, and — this is the important part — asks the founder a real clarifying question wherever the case is thin, instead of quietly patching over the gap itself.

The founder answers with real evidence, and Writer revises — up to two rounds, tracked by the mission's own state, not a hardcoded loop. None of this is orchestrated by the LLMs themselves. A deterministic Python state machine owns every transition, every revision count, and the final approval gate. The agents never get to route themselves, spawn each other, or approve their own output. That was a deliberate choice: grant-writing (and venture-building generally) is high-stakes enough that both the founder and I wanted a visible human checkpoint, not a fully autonomous black box. The "submit" button on the final review screen is permanently disabled, on purpose — GrantBuddy hands you a strong draft; it never acts on your behalf.

The bug that taught me the most

Here's the part I actually want to write about, because it's the kind of bug that looks like a typo and is actually an architecture lesson.

GrantBuddy's frontend and backend run as two separate Cloud Run services. Partway through the build, guest login and Google sign-in both started looking like they worked — the network tab showed a clean 200 OK with a Set-Cookie header — but the very next request came back unauthenticated. No error, no obvious cause. It just silently didn't work, and only in some browsers.

The root cause: *.run.app — the domain every Cloud Run service lives under — is on the Public Suffix List. That list exists specifically to tell browsers "don't treat these as one organization's domain, treat every subdomain as a separate site." Which means my frontend calling my own backend, both under *.run.app, wasn't a same-site request at all from the browser's point of view — it was cross-site. And a cross-site cookie, even one correctly configured with SameSite=None; Secure, is exactly the kind of thing Safari adefault, silently, with no console warning.

What's next for GrantBuddy: the grant-writing partner that pushes back

Real funder-specific application-form adapters (so the grounded case maps directly onto the actual form fields instead of a generic markdown export); pulling in publate assumptions automatically rather than just flagging them; multi-founder/collaborator accounts; and, if we take this toward institutional use, adopting the AgentRuntime / Memory Bank pattern for persistent cross-session context so a founder's evidence and revisions carry forward across weeks, not just one sitting.

Here's the full story rewritten around venture creation (grant-matching is now framed as one engine inside that, not the whole point). I also fixed a couple of garblh in your paste (browvice architecture, pulate assumptions).

One flag before you paste this: the last section's header — "What's next for [Project Name]" — is auto-generated by Devpost from whatever you put in the Project Namey: the grant-writing partner that pushes back as the name, that header will contradict the venture-creation framing below it. I'd switch the Project Name field toplain GrantBuddy and let the elevator pitch carry the positioning instead — I've written the closing section assuming that.

---

Inspiration

Most founders don't get stuck at the writing stage — they get stuck earlier: deciding whether an idea is worth pursuing at all, and figuring out where the money coulfrom a rough idea to something fundable means researching options, building a case, and getting the confidence to actually put it in front of someone — with almost no real-time feedback until you've already sunk hours into the wrong direction. At the same time, LLMs are great at confidently writing that case and terrible at knowing what they don't actually know — they'll happily invent a market size or "proven traction" that doesn't exist. We wanted an agent that acts like the toughest, most useful advisor a founder could have through that whole journey: one that helps you stand up a venture fast, but pushes back on anything it can't ground in real evidence, instead of just producing something that sounds impressive.

What it does

GrantBuddy is a venture-creation partner: it walks a founder from a rough idea all the way to a funded, evidence-checked case. Describe your idea (or spin the built-r for a starter example), get ranked funding matches from Scout, get a natural business-case draft from Writer with every claim tagged supported / assumption /missing, get audited by Checker — which asks a real clarifying question wherever the case is thin and lets Writer revise (up to two rounds) once you supply real evidence — and finally review a before/after comparison and approve the draft yourself. A Dashboard tracks every venture you're building (grouped by approved / in progress / draft), each one named

from your own venture, not a placeholder, so you can jump back in, delete old ones, or start a new one. External submission is permanently disabled by design — Grantdence-checked draft; it never submits on your behalf, because the founder, not the agent, owns the venture.

How we built it

A deterministic Python WorkflowController — not the LLM — owns all state, persistence, revision limits, and approval gates for every venture, and drives five specialised agents via Google ADK2 on Vertex AI: Scout, Writer, and Checker run the audited pipeline on gemini-3.7-flash, while Idea Generator and Validation Tips run on the cheaper, faster gemini-3.5-flash-lite — a deliberate cost/latency split rather than defaulting everything to the biggest model. State lives in Firestore (users, missions, mission_artefacts, workflow_events), guarded by a Firestore-backed global token-bucket rate limiter so a burst of demo traffic can't blow through our shared GCP credits. The frontend is React/TypeScript on Tailwind; both frontend and backend run as separate Cloud Run services, with the frontend proxying API/auth calls server-side so the browser only ever talks to one origin.

Challenges we ran into

The sharpest one: our guest login and Google sign-in looked like they worked (200 OK, cookie set) but silently failed for a real user on a fresh browser. Root cause suffix list, so calling the backend's Cloud Run URL directly from the frontend made our session cookie genuinely third-party, which Safari and Chrome Incognito blockby default regardless of SameSite=None; Secure. The fix was routing all /api and /auth calls through the frontend's own origin via a server-side proxy, which in turn meant re-pointing the Google OAuth redirect_uri to match — a good reminder that fixing one origin-boundary issue can quietly move where the next one shows up.

On the product side: getting the Checker's grounding rubric strict enough to catch hallucinated valuations without being so strict it constantly blocked a genuinely , and one revision round turned out to be too rigid for real evidence gaps — we raised it to two, bounded by the mission's own tracked revision count rather than ahardcoded pass.

Accomplishments that we're proud of

- A grounding loop that converts hallucinated hype into qualified, honest milestones instead of just silently deleting the claim.

- A state machine that keeps five LLM agents from ever controlling routing, spawning each other, or approving their own output — the human and the deterministic contventure throughout.

- Catching and fixing a genuinely subtle, real-world auth bug (third-party cookie blocking on a split Cloud Run deployment) that would have quietly locked out a meaningful share of judges and users depending on their browser.

- A guided, five-stage venture-building session that makes "AI wrote this" feel like a collaborative working session, not a one-shot generation.

What we learned

- LLMs reliably generate ungrounded commercial claims when writing pitch text — an explicit grounding rubric plus the founder's own follow-up evidence reliably converts hype into qualified feasibility milestones.

- Building a venture is high-stakes enough that founders and funders both want a visible human checkpoint, not full automation — we leaned into the Collaborative Parg an artificial "fully autonomous" story.

- Mixing model tiers deliberately (full model for the audited pipeline, lite model for lower-stakes generation) keeps cost and latency down without touching what's actually being judged for grounding.

- SameSite=None; Secure is necessary but not sufficient for cross-origin cookies in production — third-party cookie blocking is a separate, increasingly-default browser behavior that a split-service architecture has to design around from day one, not patch afterward.

What's next for GrantBuddy

Real funder-specific application-form adapters (so the grounded case maps directly onto the actual form fields instead of a generic markdown export); pulling in public data sources to help validate assumptions automatically rather than just flagging them; multi-founder/collaborator accounts; and, if we take this toward institutional use, adopting the Agent

Runtime / Memory Bank pattern for persistent cross-session context so a founder's evidence and revisions carry forward across weeks of building a venture, not just o

---

Want me to also propagate this framing into the README's opening tagline/Section 1, or leave the README as the more grant-specific technical doc and keep this venture framing scoped to the Devpost pitch?

✻ Worked for 39s · done 9:49 PM

※ recap: We fixed GrantBuddy's login, dashboard, and approval-flow bugs, then pushed everything for its "All Things Agentic" hackathon submission. Now finishing the Devpost writeup with a venture-creation framing; next decide whether to update the README to match or keep it grant-focused.

❯ can you help me write a blog post that I can put on my personal website compusential.com

Here's a draft blog post — longer-form and more personal than the Devpost story, built around the "how a subtle cookie bug taught us something about the architecture" angle, which tends to make for a much more compelling technical post than a straight feature list. Includes the disclosure line the hackathon rules require for content bonus points.

---

Building GrantBuddy: An AI Partner for Turning an Idea Into a Fundable Venture

This post was written as part of my submission to Google's All Things Agentic Hackathon.

A few days ago I set out to build an agent for the hackathon's "Collaborative Partner" track. The brief was simple to state and hard to do well: build something thatasks clarifying questions, and adapts based on their feedback — rather than just another chat window with a system prompt bolted on.

I picked a problem I actually understand: most founders don't get stuck at the writing stage. They get stuck earlier — deciding whether an idea is worth pursuing, fito try it, and building the confidence to put a case in front of someone. And they get almost no real feedback until they've already sunk hours into the wrongdirection.

That's what GrantBuddy is: a venture-creation partner. You bring it a rough idea, and it takes you through five stages — matching you to real funding programmes, dra, auditing every claim in that case for whether it's actually grounded in evidence, and only handing you the final draft once you and the agent have both done thework to make it defensible.

The part everyone gets wrong: LLMs are confidently wrong about evidence

The single hardest problem in this project wasn't prompting — it was grounding. Ask an LLM to write a pitch for a pre-revenue business and it will cheerfully invent en customer traction" that doesn't exist, and generally write the confident version of the story instead of the true one.

So GrantBuddy doesn't have one agent writing the case — it has three doing different jobs:

- Scout matches the idea against funding programmes and flags eligibility gaps.

- Writer drafts the case, but tags every single claim as supported, assumption, or missing. - Checker audits that draft, scores how well it's grounded, and — this is the important part — asks the founder a real clarifying question wherever the case is thin,over the gap itself.

The founder answers with real evidence, and Writer revises — up to two rounds, tracked by the mission's own state, not a hardcoded loop. None of this is orchestrated by the LLMs themselves. A deterministic Python state machine owns every transition, every revision count, and the final approval gate. The agents never get to route themselves, spawn each otheor approve their own output. That was a deliberate choice: grant-writing (and venture-building generally) is high-stakes enough that both the founder and I wanted a a fully autonomous black box. The "submit" button on the final review screen is permanently disabled, on purpose — GrantBuddy hands you a strong draft; it neveracts on your behalf.

The bug that taught me the most

Here's the part I actually want to write about, because it's the kind of bug that looks like a typo and is actually an architecture lesson.

GrantBuddy's frontend and backend run as two separate Cloud Run services. Partway through the build, guest login and Google sign-in both started looking like they worked — the network tab showed a clean 200 OK with a Set-Cookie header — but the very next request came back unauthenticated. No error, no obvious cause. It just silently didn't work, and only isome browsers.

The root cause: *.run.app — the domain every Cloud Run service lives under — is on the Public Suffix List. That list exists specifically to tell browsers "don't trea domain, treat every subdomain as a separate site." Which means my frontend calling my own backend, both under *.run.app, wasn't a same-site request at all from thebrowser's point of view — it was cross-site. And a cross-site cookie, even one correctly configured with SameSite=None; Secure, is exactly the kind of thing Safari and Chrome Incognito block by default, silently, with no console warning.

SameSite=None was necessary. It just wasn't sufficient. The fix was to stop the browser from ever talking to the backend's own origin at all — the frontend's own server now proxies /api and /auth calls to the backend behind the scenes, so from the browser's perspective there's only ever one site, and the session cookie is first-party. It's a two-line proxy config change, but finding it meant understanding a browser security mechanism that has nothing to do with anything I'd written wrong in the code.

The lesson I keep coming back to: cookies "working" in curl tells you almost nothing about whether they'll work in a real browser with real privacy defaults. If your architecture splits services across subdomains, test it in an actual browser, in an actual incognito window, before you trust it.

What it's built on

- Google ADK2 orchestrating five specialised agents on Vertex AI — the audited pipeline (Scout, Writer, Checker) runs on gemini-3.7-flash; lower-stakes generation (idea inspiration, validation tips) runs on the cheaper gemini-3.5-flash-lite. Mixing tiers deliberately turned out to matter more for cost and latency than I expected going in.

- Firestore for all state — missions, artefacts, workflow events — plus a Firestore-backed token-bucket rate limiter, since this is running on shared hackathon credits and I didn't want a burst of traffic to blow through the budget in an afternoon. - FastAPI backend, React + TypeScript frontend, both on Cloud Run.

GrantBuddy architecture diagram (https://raw.githubusercontent.com/pixjobs/grantbuddy/main/docs/architecture.png)

What's next

The obvious next step is funder-specific application-form adapters, so the grounded case maps directly onto a real form instead of a generic markdown export. After that: pulling in public data sources to help validate assumptions automatically instead of just flagging them, and — if this ever needs to support more than one founder per venture — adopting a proper memory pattern so evidence and revisions persist across weeks, not just one sitting.

If you want to poke at it yourself, the code is at github.com/pixjobs/grantbuddy and there's a live demo linked in the README.