Before the first commit, agree on what you’re building.

The first difficult part of a hackathon can happen before anybody opens an editor. A team has a theme, a deadline and several convincing ideas. Each idea sounds manageable until someone asks who will build which part, what already exists, and what the demo can honestly show.

exHacker gives that conversation a workspace. It takes the challenge, time constraints and team skills, researches possible directions, and helps the team choose a plan deliberately. The interesting artifact is not a pile of generated text. It is an agreement that stays internally consistent.

Five directions, then an actual decision

The current workflow generates, researches, critiques and ranks five candidate ideas. The critique is a separate model call, with visible reasoning and revisions. Eight explicit scores explain the ranking; capacity and evidence place limits on what those scores can suggest.

A team still selects the idea. It then reviews the proposed stack before approving it. These checkpoints are product behavior, not decorative progress indicators: later documents depend on what was actually confirmed.

After approval, the compiler produces ten Markdown files, including the PRD, architecture, database design, API, research, setup and implementation plan. The files come from one saved specification and confirmed snapshot, so the setup guide is not casually describing a different application from the API document.

What happens when the brief changes?

This is where a planning product becomes more interesting than a prompt form. Editing the intake clears the current derived context. Reevaluating ideas clears selection, stack and documents. Changing the stack clears its approval and the document package. Historical artifacts remain available.

That distinction lets someone ask why the previous plan was rejected without accidentally treating it as the current plan. Chat messages also retain their originating context revision, while future answers use the latest confirmed context.

The API uses revision checks and atomic compare-and-set when jobs complete. An older tab or overlapping job cannot quietly replace a newer decision. Approval records and follow-up jobs are committed together, so the system does not claim an approval succeeded while losing the work it was supposed to start.

A saved plan should stay saved

The browser reaches a Next.js proxy, then FastAPI, SQLAlchemy persistence and an embedded asynchronous worker. Provider adapters and research calls sit behind that boundary. Reading an existing document does not generate a replacement; repeated exports of a saved revision use fixed ZIP metadata and content hashes.

Provider credentials have a different lifetime from the project. Dedicated credential endpoints and expiring in-memory leases keep them separate from saved artifacts. If the lease expires or the process restarts, work pauses for reentry; the project does not need to disappear with the key.

That architecture requires a persistent backend process. It is not a claim that a long-running worker can live reliably inside an ordinary request-only serverless function.

The current studio and its earlier life

The earlier version won HackArena 2.0 in June 2026. I returned to the project for a July rebuild, and it has continued to change since that hackathon implementation. Older descriptions of a fixed endpoint count or a LangGraph specialist-agent system describe an earlier stage; they do not explain the current revision-based studio. Contributions to the broader evolution include an alternate frontend by Akshaj Garlapati, parts of which were adopted.

The supplied screenshots use the documented local demonstration environment. Its database, job and export paths are real; its model and research fixtures are explicitly simulated. A planning score is still advice, not proof that an idea is unique or likely to win.

The product I want at the end of that first team discussion is simple: everyone can open the same plan, understand why it was chosen, and start building without discovering that the documents disagree.