How to Find Hackathon Teammates (and Split Roles) as a Fresher

Most first-time hackathon teams don't fall apart because the idea was bad. They fall apart because four people who all wanted to write backend code realised on day three that nobody had designed a screen, written the pitch or tested the demo.

If you're a student or fresher getting ready for Productothon 01, HireDoor's free five-day build week, this guide is for you. It covers whether to go solo or build a team, where to find teammates, what to ask someone before you say yes, and how to split roles so that every part of the submission has an owner. Registration closes at 12:00 AM IST on 30 October 2026, which is also when the problem statements drop, so the next two days are your team-forming window.

First, decide: solo or team?

Going alone is a real option. Productothon 01 allows teams of 1 to 4, and solo builders are welcome. Major League Hacking, which runs student hackathons worldwide, says in its guide to preparing for a hackathon that "going solo is completely legitimate, especially for a first event", but that a team changes the experience and it's "worth deciding on purpose rather than by default".

A quick way to decide:

• Go solo if you can build a small working product end to end, you want full control over scope, and you're comfortable recording your own demo and pitch.
• Build a team if you're strong in one area (say, backend or design) and weak in others, or if you know your week will be busy and you need people to share the load.

Bigger isn't automatically better. In its organiser guide, MLH says it sees hackers "have the most success with teams of a maximum size of 4". Every extra person adds another opinion and another schedule to coordinate, so add people only when they cover something the team is missing.

What a good hackathon team actually needs

MLH's advice is that a good team "isn't built on skills alone – it's not just 'who can code.'" The strongest teams usually have someone who builds the software, someone who thinks about design and how it feels to use, and someone who can tell the story at the end. The same guide adds that a person who has never written code "can still be the reason a team wins, because the demo is what judges see."

Devpost's teamwork tips say the same thing in different words: diversify roles across front-end, full-stack, project or product management and design, and divide tasks by each person's strengths.

So think in terms of jobs to be done, not job titles. A five-day product build needs four jobs covered:

1. Build: the core feature, the backend, data and any AI or API integrations.
2. Experience: the screens, the user flow and how the product looks in a demo.
3. Product and story: the problem, who it's for, which features to cut, the pitch deck and the demo video.
4. Glue: connecting frontend to backend, deploying it, and making sure the live link works on submission day.

One person can hold more than one job. The Hackathon Playbook puts it simply: before you commit to a team, "put a name next to each role. If one is blank, recruit for it or make it someone's second job."

How to split roles by team size

Team size	Suggested split
1 (solo)	You own everything. Keep the scope to one core flow, and use a simple UI kit so design doesn't eat your build time.
2	Builder (backend + deploy) and builder-designer (frontend + UI). Whoever writes better owns the pitch and README.
3	Backend/AI builder, frontend + design, and a product lead who owns the problem, scope, testing, deck and demo video.
4	Backend, frontend, design/UX, and product/pitch. One of the builders also owns deployment and the GitHub repo.

Where to find teammates before 30 October

1. Start with people you already know, carefully

Classmates, your coding club, your hostel wing. Friends are easier to coordinate with, but a long, intense build can strain any friendship, so talk through expectations and divide responsibilities before build week starts. Don't pick three friends who all have the same skill.

2. Use Productothon Team Lab

The Productothon Team Lab is built for this. You can:

• Create a team of 1–4, set the open roles you need and share your invite code.
• Join by code if a teammate has already created a team and sent you the eight-character code.
• Browse open seats and request to join teams that need your skills. The directory filters include Frontend, Backend, Full Stack, AI/ML, DevOps, UI/UX, Product, Marketing, Research, Designer and Business.

You can also post or join an idea in the Idea Lab and recruit people who are excited about it.

3. Post a clear "looking for a team" note

MLH suggests showing up with "a one-line pitch of what you'd like to make, or what you're good at". Devpost's participant FAQ gives similar advice: add a quick intro about yourself and what you're looking for. A template you can copy:

"Hi! I'm Priya, final-year CSE. I build with React and Node and have shipped two small web apps (links in profile). Looking for a designer and someone strong on backend/AI for Productothon 01. Interested in the education and career tech or AI and automation tracks. Free 6–8 hours a day during 1–5 Nov."

Be specific: your skills, proof (a GitHub or Figma link), the role you need, the track you like and how much time you have.

Five questions to ask before you say yes

Google's research on its own teams found that "who is on a team matters much less than how team members interact, structure their work, and view their contributions". Of the five dynamics its Project Aristotle study identified, the top two were psychological safety (feeling safe to ask questions and admit mistakes) and dependability (members reliably finishing quality work on time). Google also wrote that the number of top performers on a team "emerged as a poor indicator" of how effective it was.

For a hackathon, that means you're choosing for reliability and fit as much as skill. Ask:

1. How many hours can you give each day from 1 to 5 November? Clash with exams, a job or travel? Better to know now.
2. What have you built before? Ask for a link. A small working project matters more than a long skills list.
3. What do you want out of this: to win, to learn, or a project for your résumé? Mixed goals cause fights on day four.
4. Which role do you want to own? If two people want the same role and nobody wants design or the pitch, rethink the team.
5. How will we talk and decide? Agree on one channel (WhatsApp, Discord or Slack), a daily check-in time, and who has the final word when you're stuck.

Write a 15-minute team agreement

Google's research lists structure and clarity, meaning clear roles, goals and plans, as one of the five dynamics of effective teams. For a five-day sprint, that can be a short shared doc covering:

• Goal: one sentence on what you're building and for whom (fill it in once problem statements drop on 30 October).
• Owners: one name against each job: build, experience, product/story, glue.
• Daily rhythm: a 15-minute check-in. What did I finish, what's next, what's blocking me.
• Cut rule: who decides when a feature gets dropped to protect the deadline.
• Submission owner: one person responsible for submitting before the official cutoff.
• Credit: a README section listing who built what, so everyone can put the project on their résumé honestly.

Map your roles to the Productothon submission

The Productothon About page lists suggested submission fields (exact requirements will be published with the event rules). Give every field an owner on day one:

Submission field	Natural owner
Product name, problem statement, problem being solved, proposed solution	Product/story
Key features, technology stack, GitHub or source-code link	Build
Live demo or working prototype	Glue (with build)
Demo video, pitch deck or presentation	Product/story with experience
Team member details	Submission owner

The proposed judging weights on the same page (not yet official) are problem understanding and solution 25%, execution and functionality 25%, innovation and originality 20%, design and user experience 15%, and impact and scalability 15%. Design, the problem and the story together carry real weight, which is another reason not to build a team of four backend developers.

Red flags to watch for

• Vague availability: "I'll join when I can" during a five-day build usually means you won't see them.
• Everyone wants the same role: nobody owns the UI, the deck or testing.
• The idea is locked before the problem drops: final challenges follow the official problem statements, so stay flexible within your preferred track.
• No proof of work and no willingness to learn: beginners are fine; people who won't show anything or pick up a task are not.

Your checklist for the next 48 hours

1. Register for Productothon 01 (free, with a HireDoor account) before 12:00 AM IST on 30 October.
2. Decide solo or team, and list which of the four jobs you can own.
3. Create or join a team in Team Lab, and post your one-line pitch.
4. Ask your shortlisted teammates the five questions above.
5. Write your team agreement, then read the problem statements together when they drop.

A team project you shipped in five days, with your role clearly written up, is exactly the kind of proof that helps on a fresher application. When you're ready to use it, browse the latest internships and fresher jobs on HireDoor, and see our guide on putting a hackathon project on your résumé.