ContestPilot

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for ContestPilot

Inspiration

Contest requirements, proof, testing, and publication decisions are usually scattered across tabs and folders. That makes it easy for a solo builder to mistake activity for evidence. ContestPilot is an evidence-first control plane for indie builders and small teams: it helps them decide what is viable, makes missing facts visible, and keeps human identity, credentials, and submission authority intact.

OpenAI Build Week added a deliberately hard proof case: could Codex build a product that creates a specialist AI for the next product? The recursion is evidence of the method, not the customer problem.

What it does

ContestPilot turns owner-reviewed, source-linked contest records into an execution queue. A user selects a contest, then the server-side GPT-5.6 lane forges a contest-specific specialist with a mission, target user, architecture, guardrails, build phases, and evidence plan. The user can inspect, revise, reject, or approve that plan before the builder starts.

The builder accepts human guidance, proposes complete source files, then automatically writes accepted files to durable storage, reads the exact snapshot back, rehydrates a fresh isolated Cloudflare Sandbox, runs fixed install/test/build commands, and returns stdout, stderr, exit codes, file hashes, and a receipt. There is no ceremonial Save or Test button: approving the build means files; files mean verification.

How we built it

Codex conceived and implemented ContestPilot with GPT-5.6. Bryan supplied the objective, constraints, resources, and final authority over identity, credentials, publication, and submission. The stack is TypeScript, Node.js, React 19, Vinext/Vite, Cloudflare Workers, Durable Objects, Cloudflare Sandbox, and server-side OpenAI Responses. Provider credentials never enter the browser.

The decision engine validates hostile data fail-closed. The UI derives from the same reviewed records and ranking code, does not scrape Devpost, and keeps unresolved eligibility visible. The public judge path has private scoped sessions, durable redemption, per-session limits, and a daily account-level allowance.

Challenges

The difficult bugs were the ones a screenshot can hide: a production page that hydrated incorrectly, model requests whose response body stalled after headers, stale deployment identity from the asset CDN, and an interface that made persistence feel optional. We repaired each with a regression test or a live receipt. The release manifest now runs Worker-first with no-store semantics, so the public identity cannot silently point at a cached earlier build.

Accomplishments

• 74 ContestPilot executable tests: 33 decision/release-safety, 30 production dashboard/forge, and 11 judge-runner policy tests.
• A full 30-step release gate also clean-packages the project, scans for secrets, reruns packaged tests, audits dependencies, and tests the protected judge path.
• A live public run forged a specialist, persisted generated files, rehydrated them in a fresh sandbox, and returned bound workspace and build receipts.
• The final judge video shows the same live product path, not a slide-only concept.

What we learned

Automation becomes trustworthy when it makes uncertainty more visible, not less. A model can move quickly, but only a durable artifact, a fixed command, and a current receipt support an implementation claim. The human stays in charge of the objective and the final yes.

What's next

ContestPilot's contest workflow is a proving ground for a broader pattern: evidence-first shipping for launches, client work, grants, and other deliverables where a claim must be reconstructable.

Built With

• cloudflare-workers
• codex
• gpt-5.6
• openai-api
• react
• typescript