Shipped

A Hackathon-completion engine: helping first time hackers click submit!

Comment 2

Inspiration

There are many productivity tools out there that help teams connect, solve problems, and execute challenging builds. But most of them are daunting for first time or solo hackers. Imagine having to set up a Slack account and connecting with everyone necessary even before your first hackathon begins. I also noticed the dropoff in hackathon completion as participation scaled - over the 200-250 range, projects stagnated at around 75-125. The bigger hackathons are also beginner friendly, even more so than the smaller ones! That's why participation significantly declined. I wanted to build a tool that helps these numerous first-time or second-time hackers brainstorm, create, and present their project. This way they weren't left signing up, they could actually ship!

What it does

Shipped is an AI completion engine that takes a first-time or solo hacker from "registered and unsure" all the way to "submitted." It isn't a productivity dashboard with an AI panel bolted on — the AI is the core, and its only job is to get you across the finish line.

It does three things, chained into a single motion:

  • Cuts scope. You paste in your idea, and it partitions it into must-have, should-have, and cut-this — each with a reason tied to the hours you actually have left. Where every other AI tool adds, this one ruthlessly removes, because over-scoping is the #1 way first-timers never finish.
  • Builds a real plan. The moment you commit the cut, it generates a time-boxed milestone plan — each milestone auto-broken into 2-4 concrete, checkable tasks. You never stare at a blank "add a task" box. Progress flows upward automatically: tick the tasks, and milestone status updates itself.
  • Re-plans when you fall behind. It checks your plan against the real clock. When you're behind, one click re-scopes toward the smallest thing you could still demo — it slides out the lowest-priority milestones (with a supportive reason), re-times what's left, and never touches work you've already finished.

The thing that makes any of this work is event-awareness. The tool knows this hackathon's real deadline, submission requirements, and judging criteria, and every cut, estimate, and re-plan is reasoned against them — something the general AI assistant in your other tab can't do.

How we built it

  • Backend: FastAPI (Python). Frontend: React + Vite. LLM: OpenAI with structured outputs — typed JSON, so we're never fragile-parsing free text.
  • One guiding principle above all: the clock never does judgment, and the LLM never does arithmetic. Every time and scheduling number is computed deterministically in Python; the model only decides what to cut and writes the rationale. That split is why the demo can run fully live — a language model can't hand us a wrong number on stage.
  • The AI orchestrates; you commit once. Committing a scope auto-chains apply → plan generation → task breakdown as one visible sequence, then collapses the setup into a summary. No capability hides behind a second button on another tab.
  • Event-awareness is a first-class object. We modeled an explicit EventContext (deadline, submission requirements, and judging criteria as {name, description} pairs, pre-seeded with the real United Hacks values) that every capability reasons against.
  • Consistency is enforced server-side. Any mutation that invalidates a milestone prunes its tasks in the same request, and surviving done-status is always preserved — no sequence of clicks can leave the plan in a broken state.
  • The re-planner is a deterministic solver. We reserve a fixed submission buffer (2h for packaging the video, writeup, and deploy), subtract it from hours-remaining to get available build time, then keep the longest priority-ordered prefix of milestones that fits — always retaining at least the single most critical one, so the plan never collapses to nothing. The LLM is called only to narrate why the cut items were dropped.

Challenges we ran into

  • Deciding what not to build. Our original plan included a "judge-lens" feature that scored your draft pitch against the rubric. We cut it — it pulled the product back toward being a review tool and pulled the user toward wordsmithing instead of shipping. Fittingly, we cut it using our own tool's methodology: it didn't serve the core, so it went.
  • Keeping the LLM away from math. Early on, letting the model estimate and schedule produced confident, wrong timelines. Splitting responsibility — deterministic clock, generative judgment — fixed reliability and, as a bonus, made the whole thing safe to demo live.
  • Preventing orphaned state. Re-planning, plan regeneration, and manual deletes could all leave tasks pointing at milestones that no longer existed. Enforcing cascade-and-preserve on the server in a single request was less glamorous than the AI work but essential.
  • Making "you're behind" feel supportive, not punishing. A red warning just adds stress. Turning the behind-state into a one-click, encouraging re-scope was a design problem as much as a technical one.

Accomplishments that we're proud of

  • A grounded problem, not a vibe. We pulled real registration-vs-submission numbers from four hackathons (United Hacks V5 & V6, HackAmerica, FutureHacks) and found that pooled, roughly ~75% of registrants never submit — and that the gap widens at exactly the large, impersonal events that draw the most first-timers. The product targets a measured failure, not a guess.
  • An AI tool that subtracts. In a field of assistants that pile on features, we built one whose signature move is telling you to do less — and it's the honest answer to why people don't finish.
  • A demo that runs fully live. Because arithmetic is deterministic, we could put a session clock-offset in and fast-forward "falling behind" in seconds, with no scripted fallback and no risk of a bad generation.
  • Restraint as a feature. We consciously deferred auth and multi-hackathon history so v1's hours went into the completion engine, not a login screen.

What we learned

  • The barrier stopped being code. With agentic AI tools, writing the code is the easy part — what actually stops first-timers is scoping, clock management, and nerve. Building for those is a different and more valuable product.
  • Constraints are the feature, not a limitation. The tightest, most useful part of the app is the deterministic re-planner — a hard clock and a priority order do more for a panicking hacker than any amount of open-ended chat.
  • Cutting scope is a skill you have to practice on yourself. Killing the judge-lens feature under our own deadline taught us the exact discipline the product is meant to give its users.
  • A believable number beats a big number. Presenting a defensible ~75% range with its caveats is stronger than a dramatic figure that falls apart under one question.

What's next for Shipped

  • Finish the Submission Driver. The per-event requirement checklist is in; next is deadline-aware reminders that fire before the buffer window so nobody hits the packaging step by surprise.
  • The v2 scale path: accounts + history. Deliberately deferred for v1, this is the real growth direction — with multi-hackathon history, the engine can calibrate its effort estimates to you, learning how you actually work across events.
  • Auto-ingest event context. Replace the manual setup form by reading a hackathon's deadline, requirements, and rubric straight from its page.
  • Sharper estimates. Feed real completion data back into the model so first-timer effort calibration keeps improving.

Built With

Share this project:

Updates