Builder Guide

HackSpire'26 shortlists teams from PPT submissions before the on-site hackathon. A clear idea and a strong deck help you earn a seat — and give your team a sharper plan for the 26 hours.

• Register your team (2–4 members) within the official registration window.
• Submit your PPT using only the official organizer template.
• Approvals happen in batches — check email regularly for First / Second / Final round approvals.
• Shortlisted teams receive further instructions for the 26-hour on-site hackathon at FIEM.

• Problem clarity — can someone understand the issue in under 30 seconds?
• User impact — who benefits, and how much does it matter?
• Originality — is this a fresh angle, not a clone of a famous product?
• Feasibility in 26 hours — can a student team ship a working demo?
• Tech sense — does the stack fit the problem, or is it buzzword stuffing?
• Team readiness — roles, strengths, and a believable build plan.

Pick a problem you can explain simply and care about deeply. Great hacks start from real friction — not from a trendy tech keyword.

• Start from a real pain: campus life, healthcare access, local businesses, farmers, students, accessibility, safety, climate, or civic systems.
• Ask: who is the user, what is broken today, and what does “fixed” look like?
• Prefer a narrow, sharp problem over a vague “AI for everything” idea.
• Choose a theme track you can honestly own (AI, Web3, IoT, Sustainability, Healthcare, Open Innovation, etc.).
• Validate quickly: talk to 2–3 people who face the problem, or observe a real workflow.
• Kill ideas that need months of data collection, expensive hardware, or legal access you won’t get before the hack.

Hundreds of teams may submit similar themes. Differentiation is why yours gets remembered.

• Own a specific niche — “attendance app” is weak; “offline attendance for rural classrooms with no stable internet” is stronger.
• Show a unique insight: a constraint, a local context, or a user behavior others ignore.
• Design one killer workflow end-to-end instead of ten half-finished features.
• Combine domains thoughtfully (e.g., IoT + accessibility, AI + vernacular language, maps + civic reporting).
• Make the demo visual and human — screens, sensors, or a before/after story that judges can feel.
• State what you will NOT build. Scope discipline is a signal of maturity.

Avoid these common traps:

• Rebuilding ChatGPT / Uber / Instagram with a thin wrapper
• Slides full of logos and no user journey
• Claiming “blockchain + AI + IoT” with no reason for each
• Ideas that only work with perfect datasets you don’t have

Use only the official HackSpire PPT template from hackspire.tech. Outside templates are not accepted. A strong deck helps reviewers understand your idea — and helps your own team stay aligned while building.

• Slide 1 — Team: names, college, contact, roles (frontend / backend / ML / design).
• Slide 2 — Problem: who suffers, what happens today, why it matters now.
• Slide 3 — Solution: your product in one clear sentence + 3 core features max.
• Slide 4 — User flow: simple screens or steps from start to “problem solved.”
• Slide 5 — Tech stack: honest tools you can actually implement in 26 hours.
• Slide 6 — Novelty: what makes this different from existing apps or past hacks.
• Slide 7 — Feasibility & impact: MVP scope, risks, and measurable outcomes.

Writing and design tips:

• Prefer short bullets and diagrams over paragraphs.
• Use real numbers when possible (time saved, users reached, error reduced).
• One idea per slide — don’t cram the entire product into one wall of text.
• Spell-check names, college, and theme labels carefully.
• Export/upload early; don’t wait for the last hour of the submission window.

You don’t need paid APIs or fancy credits to ship a strong demo. Use free and student-friendly tools wisely.

• Hosting & frontend: Vercel, Netlify, GitHub Pages, Cloudflare Pages
• Backend & databases: Supabase free tier, Firebase Spark, MongoDB Atlas free, PlanetScale/Neon free tiers where available
• Auth: Clerk free tier, Auth.js, Firebase Auth, Supabase Auth
• AI: open models via Groq / Hugging Face / local Ollama; keep prompts small and cache results
• Maps & location: OpenStreetMap, Leaflet, MapLibre
• Design: Figma free, Lucide/Heroicons, public illustration packs with proper licenses
• Datasets: Kaggle, data.gov.in, Open Government Data, Hugging Face datasets
• Learning & docs: MDN, freeCodeCamp, official framework docs, Discord mentor channels

• Define the “hero demo” first — the one path judges must see working.
• Split roles early: one person owns UI, one owns API/data, one owns integration/demo.
• Use boilerplate and starter kits; don’t reinvent auth, routing, or forms.
• Keep a fallback: if the fancy model fails, show a rule-based or mocked happy path.
• Commit to Git early and often; broken last-minute zips lose hours.
• Reserve the final 2–3 hours for polish, README, and presentation rehearsal.

• Pick teammates with complementary skills, not just friends who code the same stack.
• Assign a “story owner” who can explain the problem and demo clearly.
• Write the PPT together, then have one teammate rewrite it for clarity.
• Join the official Discord early — announcements, template updates, and mentor tips land there first.
• Practice a 60-second pitch: problem → solution → why us → what we’ll demo.

• PPT not on the official template
• Problem is unclear or too broad
• Idea is a direct clone with no local/original twist
• Tech stack looks impossible for 26 hours
• No user, no impact, only features
• Incomplete team details or last-minute rushed submission
• Ignoring announcement emails and missing deadlines

• Official template used
• Problem stated in one plain sentence
• Solution and 3 features only
• Clear user + impact
• Realistic 26-hour MVP
• Honest tech stack
• Differentiation called out
• Team details complete
• File uploaded before the deadline