--- slug: hackathon-spec-with-draftlytic title: "Spec a Hackathon Project in 30 Minutes with Draftlytic" excerpt: "Hackathon spec in 30 minutes: how to use Draftlytic's Brief depth and AI Scan to ship a working hackathon project before the clock runs out." primaryKeyword: "hackathon spec" publishedAt: 2026-08-13 readingTimeMin: 6 author: "Robert Boylan" tags: - hackathon - draftlytic - mvp-scope - ai-coding-tools - indie-dev --- It's hour two of a 48-hour hackathon. Your team has been arguing about what the app actually does for forty minutes. Someone opens Cursor and starts prompting. By hour six, you have three half-built features that don't talk to each other, and the demo deadline is closer than you thought. This is the failure mode of every hackathon team that skips the spec step. Hackathons aren't won by the team that codes fastest; they're won by the team that decides fastest and ships a coherent thing. A hackathon spec doesn't need to be a 12-page PRD (product requirements document, basically a written plan for the app). It needs to be a tight, agreed shape that lets every teammate and every AI tool work in the same direction. This post walks through how to build that hackathon spec in under 30 minutes using Draftlytic, and what to skip so you can get back to building. ## Why hackathons need a spec more than other projects Counterintuitive, given the time pressure, but true. Long-running projects can absorb a wandering direction; you have weeks to course-correct. Hackathons can't. You have hours. Every wasted prompt is two hours of the timeline gone. The teams that win hackathons agree on three things by hour two: - What the app does in one sentence - The two or three features that make the demo work - The platform and stack everyone uses Most teams skip writing this down, then drift on every point throughout the build. Writing it once, fast, fixes it. The other reason a spec matters for hackathons specifically: hackathon teams usually mix skill levels. There's a designer, a developer, a half-developer who mostly vibes with AI tools, and a "product person" who's never opened an IDE. A written spec is the only thing that keeps all four working on the same app. If it lives in someone's head, three of the four are guessing. ## Open Draftlytic, set depth to Brief [Draftlytic has three depth levels](/blog/picking-draftlytic-depth) for project creation: Brief, Standard, and Detailed. Brief asks fewer questions, generates faster, and produces a tighter spec. For a hackathon, this is the right choice every time. You don't have time for Standard's nuance, and Detailed is overkill for a 48-hour build. Brief depth means roughly: - Five to seven questions instead of twelve - A leaner generated project (no design-style deep-dive, no exhaustive personas) - Less time to first usable spec Open the project creation flow, set the depth slider to Brief, and write a one-paragraph description of the idea. Real description, not marketing copy. "An app where conference attendees can post questions to a live Q&A board and the speaker sees them ranked by upvotes" beats "an engagement platform for events." ## Skip the v2 sections Draftlytic generates a structured project with sections like features, tech stack, target audience, design style, navigation, and more. For a hackathon, most of these don't matter for the next 48 hours. Be deliberate about which ones you fill in and which you leave blank. What matters for a hackathon: - **Name**: agreed in five seconds, used for the GitHub repo and the demo - **Overview**: one paragraph the team can repeat back - **Features**: the must-haves only, three to five of them, no nice-to-haves and no future ideas - **Tech stack**: whatever the strongest builder on the team is fastest in - **Platform**: web (default for hackathons because you can demo at a URL) What doesn't matter for a hackathon: - Personas, copy tone, brand voice, accessibility patterns - Detailed external services beyond auth and a database - Pricing model (you're not selling this in 48 hours) - Future versions, archived features When the generated project comes back, ruthlessly delete or ignore anything outside the first list. Don't fight the AI for getting it "right" on sections you're not building; just skip them. ## Run the AI Scan before you start prompting This is the step most hackathon teams will skip and shouldn't. After Draftlytic generates the project, hit the "Scan with AI" button. The [AI Scan](/blog/ai-scan-finds-spec-gaps) reads the whole spec and flags places where the AI-generated content is vague, missing acceptance criteria, or contradicts itself. Why this matters more in a hackathon: a vague feature description quietly turns into 90 minutes of misery when the AI implementing it has to keep guessing. "Users can vote on questions" leaves out: anonymously or signed in? One vote per user or unlimited? Can you change your vote? The Scan catches this in ten seconds. Fixing it before you prompt saves an hour of "wait, that's not what I meant" loops. Apply every Scan fix that's about a must-have feature. Skip fixes about features you've decided not to build. The whole scan-and-fix pass takes five minutes and pays for itself three times over. ## Export the implementation plan for your AI tool Once the spec is tight, export the implementation plan. The Export menu has an "Implementation plan document" option that generates a step-by-step build plan, formatted to fit in an AI coding tool's context window. Paste this into whichever tool your team is using. For a 48-hour hackathon with mixed skill levels, two paths work well: - If the team is developer-heavy, paste the plan into Cursor or Claude Code and work file-by-file - If the team includes designers and non-coders, drop the plan into Lovable, v0, or Bolt.new for the first scaffold, then move to Cursor for the polish The implementation plan is what makes the prompts you'll write next actually fit together. Without it, every teammate is prompting against their own interpretation of the spec. With it, everyone's working from the same numbered checklist. ## A worked example: idea to first commit in 45 minutes Real example, slightly adapted. Hackathon team of three: a developer who lives in Cursor, a designer who prefers v0, and a product person who's mostly there for the pitch. Hour zero: they agree on "conference Q&A tool" as the idea. 10 minutes of arguing about features. Hour 0:10: they open Draftlytic, depth Brief, write the description. Generation takes about 90 seconds. They get back: name suggestion, overview, four features (post question, upvote, mark answered, moderator view), suggested stack (Next.js + Supabase), target audience (conference attendees). Hour 0:13: they run AI Scan. It flags: "post question" doesn't specify anonymous vs signed-in, "upvote" doesn't specify whether you can vote multiple times, "moderator view" doesn't say who counts as a moderator. They apply three fixes. Two minutes. Hour 0:18: they export the implementation plan. Twelve numbered steps, from "create the Supabase project" to "deploy to Vercel." Hour 0:20: the developer pastes steps 1 to 5 into Cursor. The designer takes the design style and starts in v0 on the question card layout. The product person writes the demo script using the overview as the source of truth. Hour 0:45: first commit. Working data model, blank UI, auth wired up. The remaining 47 hours go to the feature work. This isn't a fantasy timeline; this is what happens when the spec is tight before the build starts. The "wasted" 45 minutes at the front saves four hours of prompting in circles later. ## What to actually skip and what to keep A 30-minute hackathon spec is about being deliberate about what's worth writing down right now. Keep: a one-paragraph overview, three to five features with acceptance criteria, the stack, the platform, and a working data-model sketch (which Draftlytic generates as part of the spec). Skip: marketing pages, exhaustive personas, copy tone, design system tokens beyond a primary color, future features, monetisation, and analytics. All of these have their place in a real product. None of them help you ship in 48 hours. The win condition for a hackathon spec is "every teammate and every AI tool can answer 'what are we building right now' the same way." That's it. Anything beyond that is overhead. Draftlytic was built for the full lifecycle, but the speed run works too. The depth slider exists so the same tool that produces a 12-section spec for a real product can produce a tight three-page spec for a hackathon. Use it that way, and the front of the build stops being the bottleneck. Forty-five minutes from idea to first commit. The clock starts when the team stops arguing and opens [the project creation flow](/what-is-a-prd). Most of the difference between a hackathon win and a hackathon dud lives in those forty-five minutes.