Building an AI-native
funding workflow.

FundRobin is an AI-native grant discovery and proposal-writing product built for nonprofits. The useful design problem is broader than “put AI in a grant tool”: it is how to move from finding an opportunity to making a defensible decision and producing useful work without losing context or control.

The product problem

A good match is only useful if the next step is clear. A good draft is only useful if it is grounded in the organisation, the opportunity and the required application structure. A reliable workflow therefore has to preserve state between stages, expose uncertainty and create explicit places for review.

That changes the design unit. Instead of optimising a single prompt, the product has to manage a chain of decisions: what data enters the system, which logic should remain deterministic, where models add value, how outputs are checked, and what happens when a step fails.

AI-assisted products inherit the ordinary constraints of software and add new ones. Inputs may be incomplete. Source information changes. Model behaviour varies. Long-running jobs fail. Providers throttle or become unavailable. A confident answer can still be wrong.

A useful architecture question

For each stage: what must be deterministic, what can be probabilistic, what evidence must be retained, and what should the system do when confidence is insufficient? Those questions create a more durable architecture than choosing a model first.

Design the workflow, not the prompt

The first decision is conceptual: each meaningful stage gets a clear input, output and failure condition. That creates natural points for validation, retries, escalation and instrumentation. It also makes the user experience easier to reason about because the product can explain what it is doing rather than hiding everything behind one “AI” action.

Keep deterministic structure around probabilistic work

Where business rules, eligibility logic, state transitions or billing boundaries can be explicit, they should be. Models are then used where interpretation, synthesis or drafting benefits from them. The goal is not to minimise model use; it is to use models where their strengths are valuable and surround them with enough structure to make the overall system dependable.

Make recovery a first-class capability

Production work does not fail politely. Jobs time out, structured outputs break, providers fail, and users revisit work later. The production system therefore includes provider fallback, asynchronous processing, unfinished-run recovery, evaluation workflows, usage and cost telemetry, and explicit human approval controls. Those capabilities matter because they let the product recover without hiding uncertainty or leaving users guessing about state.

Evidence is most useful when it explains scale, pace or operating effectiveness rather than acting as decoration.

250+

CustomersOrganic customer growth since launch.

12,000+

Grants processedOpportunities processed through the product workflow.

~1 week

Well-scoped feature cycleA well-scoped idea can move from concept to working product or production feature in approximately one week using the current AI-native delivery model.

These figures describe product scale and delivery pace; they are not presented as proxies for customer outcomes.

The strongest lesson from building and operating the product is that applied AI product leadership is largely boundary design: between deterministic logic and model reasoning, autonomy and review, local context and durable knowledge, speed and verification.

That is also where strategy and engineering meet. The strategic question is what work should become possible. The product question is where the user needs control. The architecture question is which state and guarantees make that experience credible. Treating those as one connected problem has become central to how I approach AI product work.