Caddie

Ideate, Plan, Build, Share/Submit.

Comment

Inspiration

I wanted to make the journey from “I have an idea” to “I have something working” accessible to people who cannot spend their time managing development tools.

Hackathons make that problem especially visible. A builder must find a suitable opportunity, understand its rules, choose a feasible idea, build it, test it and prepare the submission. Each step can become a separate project.

Caddie brings those responsibilities into one persistent assistant. You describe the outcome, review its plan, choose a look and try the application it builds. Along the way, Caddie keeps evidence of what it actually checked.

What it does

Caddie follows a connected journey: Find → Plan → Build → Prove → Ship.

It discovers open hackathons using live sources, reads their rules and presents cited information about fit and requirements. It helps shape an idea into a versioned plan, proposes visual directions and asks for approval before building.

A coordinator delegates implementation to specialists with restricted tools. Generated code runs in isolated Nebius Token Factory sandboxes, where Caddie installs dependencies, executes tests and builds the application.

Caddie then runs its own browser checks against the approved behavior. Build activity shows which parts passed, what failed and what needs another attempt. The finished application becomes available in a preview, and Caddie prepares the contest’s hand-in list for the human to submit.

Our completed example is EggOps Nigeria, an egg-farm application for Nigerian poultry farmers. Caddie planned, designed and built it in four parts, then checked the result. This journey ran with Caddie locally connected to real Token Factory models and sandboxes.

How we built it

Caddie is a TypeScript application hosted on Cloudflare Workers. Flue agents use Durable Objects for execution, D1 stores product state, React provides the workspace and Astro serves the landing page.

Nebius Token Factory supplies both model inference and sandbox execution. NVIDIA Nemotron powers the conversation, idea exploration, architecture review, rules reading, opportunity ranking, image understanding and AI inside generated applications.

Different models handle different responsibilities. Ultra supports deeper reasoning, Super VL handles conversation and images, Nano supports repeated background tasks, and Lightning serves responsive in-app AI. Other hosted models contribute planning, design, implementation and repairs.

Tavily is part of the runtime: search discovers opportunities and supports research, while extraction retrieves pages for rules reading. Caddie checks proposed quotations against stored source snapshots.

Approvals bind to specific revisions. The host controls checks and completion, and independent acceptance runs outside the builder’s workspace. Results are tied to the particular build being evaluated.

Challenges we ran into

The hardest challenge was making the entire journey dependable.

Models could write plausible code while missing an approved behavior. Repairs sometimes broke passing tests. Browser journeys could also be wrong: a check might expect saved data without first entering any. Long conversations introduced runtime and recovery problems.

The EggOps journey exposed these issues directly. We improved repair feedback so the builder received the checker’s actual failure, added validation for impossible journeys, clarified routing requirements and reduced the size of first versions.

Model behavior also varied substantially by task. Some reasoning calls consumed too much time or exhausted their output allowance before producing a usable answer. We adjusted reasoning settings and model routing based on recorded runs.

The successful build required development intervention, and a complete build on the deployed Worker remains a separate verification milestone.

Accomplishments that we're proud of

I am proud that Caddie completed a real application through its own planning, design, implementation and verification workflow.

EggOps Nigeria made the product’s purpose tangible: a specific idea became software that could be opened, exercised and checked.

I am equally proud of the evidence mechanism behind that result. Caddie records machine-executed checks, keeps verification separate from implementation and refuses to accept a model’s own success claim as proof.

The project also connects opportunity discovery and submission preparation with the build itself, giving the work a clear purpose from the beginning.

What we learned

We learned that model quality depends on the job. A model that works well for conversation or screenshots may be a poor choice for a difficult code repair.

We learned that verification needs its own verification. Running a browser independently is valuable, but the journey must correctly represent what the user wanted.

We also learned that failure handling is part of the product. Saved work, understandable pauses, precise repair feedback and safe continuation matter as much as the first successful response.

Above all, we learned to measure progress through working behavior and recorded evidence.

What's next for Caddie

The next chapter is making the successful journey repeatable for people who did not build Caddie.

That means strengthening long-running hosted execution, simplifying recovery, measuring completion time and cost across more projects, and learning from a small group of independent users.

The longer-term direction is a dependable assistant that helps people find worthwhile opportunities and carry their ideas through to useful, verifiable software.

Built With

Share this project:

Updates

Submission history