On this page
- Use the hackathon to test a problem, not prove your idea
- Choose a narrow user and a painful workflow
- Run discovery interviews while everyone else is coding
- Build only what can change your mind
- Treat feedback as data, not validation
- Turn the weekend into a four-week test
- Make discovery a founder habit after college
At a 24-hour hackathon, the team that ships the most polished demo often gets the loudest applause. Student founders who keep building after the event need something more useful: evidence that a real person has a repeated, costly problem. Student founders hackathon customer discovery is about treating the event as a field test for assumptions, not as a finish line for code.
Use the hackathon to test a problem, not prove your idea
Most student teams enter a hackathon with a solution in mind. They pick AI, a marketplace, a dashboard, or an app, then search for a problem that can justify it. That approach produces fast demos but weak startup decisions. Your job is to reverse the order: start with a person, understand their work, and then test whether your proposed solution changes anything meaningful.
Pick one user group you can reach during the event. It could be hostel wardens handling maintenance requests, placement coordinators sorting student records, small retailers managing stock, or student clubs collecting payments. Avoid broad labels such as “students” or “small businesses.” A useful user group has a shared context, a visible workflow, and a problem you can investigate in a few conversations.
Before the opening ceremony, write down three assumptions: who has the problem, how they handle it today, and why the current method fails. Each assumption should be capable of being wrong. If you cannot describe what would disprove your belief, you are preparing a pitch, not doing discovery.
- Weak assumption: Students need a better productivity app.
- Testable assumption: Final-year engineering students miss project deadlines because tasks are split across WhatsApp, spreadsheets, and informal group chats.
- Useful evidence: Multiple people describe the same failure, show you their current workaround, and agree to try a specific alternative.
Choose a narrow user and a painful workflow
A hackathon gives you limited time, so your discovery scope must be narrow. Do not try to understand an entire sector in one weekend. Find one workflow where a person repeatedly spends time, loses money, makes errors, or depends on another person to get work done. The tighter the workflow, the better your questions become.
For student founders in India, proximity is an advantage. Your campus, family networks, local shops, clinics, tuition centres, delivery workers, and student communities can give you access that an outside founder may not have. Use that access with care. A familiar user is not automatically a validated customer; you still need to observe behaviour rather than accept polite encouragement.
Frame the problem through a recent event. Ask someone to walk you through the last time they faced it. What triggered the task? What did they do first? Where did they get stuck? Who did they ask for help? What did the delay or mistake cost them? A detailed story gives you better product inputs than a general opinion.
| Question to avoid | Question to ask instead |
|---|---|
| Would you use an app for this? | How did you handle this the last time it happened? |
| Do you think this is a problem? | What part of this process takes the most effort? |
| Would you pay for our product? | What are you paying for now, in time or money? |
Run discovery interviews while everyone else is coding
Make customer conversations a workstream, not a task you postpone until the demo is ready. Split the team early. One or two people can prototype while another person schedules calls, visits potential users, or speaks to people at the venue. If all founders code for 18 hours and interview nobody, you may ship quickly in the wrong direction.
Set a minimum target before the event begins. For example, aim to speak with people who fit the same user profile, then compare their stories for repeated patterns. You are not looking for praise. You are looking for urgency, existing workarounds, and signs that the problem occurs often enough to matter.
Take notes in the user’s language. Record direct phrases, the steps in their process, tools they already use, and objections to changing behaviour. Do not write “user likes concept.” That statement is too vague to guide product work. Write what they currently do, what breaks, and what they agreed to do next.
- Open with their work or routine, not your idea.
- Ask about a recent incident and follow the sequence of actions.
- Identify the existing workaround, including spreadsheets, calls, WhatsApp groups, and manual records.
- Show a rough concept only after you understand the current process.
- End with a commitment: a trial, an introduction, a follow-up call, or permission to observe the workflow again.
Build only what can change your mind
A hackathon prototype should answer a decision, not display every feature your team can build. If your uncertainty is whether users will upload documents, build the upload flow. If your uncertainty is whether a business will trust automated recommendations, show the recommendation with a clear explanation and ask for a real response. Keep the product surface small enough that you can change it after each conversation.
Use the prototype as a conversation tool. A clickable flow, a simple landing page, a manual service behind a form, or a spreadsheet-backed mock-up can reveal more than a full application. The right format depends on the assumption. Technical complexity does not make evidence stronger.
Track three kinds of signals. First, did users recognise the problem without you explaining it? Second, did they describe a current workaround that proves the problem is active? Third, did they take a concrete next step? A request for a demo, permission to test with their team, or an introduction to the person who controls the workflow carries more weight than “This is a good idea.”
This is where a student team can separate demo theatre from founder work. Your goal is not to make judges imagine demand. Your goal is to leave the event knowing what to test next, what to remove, and which user segment deserves another week of attention.
If you have evidence but need help turning it into an investor-ready fundraising case, Apply for Nebula 1.0. Our current live program is a 2-week fundraising sprint for founders preparing to make sharper funding decisions.
Treat feedback as data, not validation
Hackathon feedback arrives from mentors, judges, peers, and users. These groups serve different purposes. Mentors may improve your framing. Judges may assess your presentation. Peers may point out technical alternatives. Only a person who experiences the target problem can tell you whether your problem definition matches daily reality.
Sort every comment into a simple evidence log. Do not let a confident opinion overrule repeated user behaviour. A judge may ask for a feature that makes the demo stronger but pulls you away from the workflow users actually described. Capture the suggestion, then return to your problem statement and interview notes.
| Signal | What it means | What to do next |
|---|---|---|
| “Interesting idea” | Polite interest, not proof of need | Ask about the last time the problem occurred |
| User shows a workaround | The problem may be active and repeated | Measure the cost, frequency, and limits of that workaround |
| User asks to try it | There is a reason to run a focused test | Set a date, define the test, and follow up |
| User introduces a decision-maker | Your learning path may have expanded | Prepare questions for the buyer or operator |
Strong discovery creates clarity even when it delivers bad news. If conversations show that the problem is infrequent, the buyer is inaccessible, or the current workaround is good enough, do not defend the original concept. Narrow the segment, change the workflow, or stop. Killing a weak assumption early saves time.
Turn the weekend into a four-week test
The real value of a hackathon appears after the event. Within 48 hours, send follow-up messages to every person who offered help, requested access, or agreed to speak again. Refer to the specific issue they described. A generic “Thanks for your feedback” message loses the context you worked to earn.
Choose one measurable learning goal for the next four weeks. It could be to observe five users complete the same workflow, get three people to test a manual version of the service, or learn who approves payment for the problem. Do not set a goal such as “grow the startup.” Early work needs a question that produces a clear answer.
- Week one: Clean interview notes, group recurring patterns, and write a revised problem statement.
- Week two: Test the smallest product flow that addresses the repeated pain point.
- Week three: Ask for a higher-commitment action, such as a pilot, referral, or access to real workflow data.
- Week four: Review evidence with your team and decide whether to continue, narrow, change direction, or stop.
Keep a record of decisions and the evidence behind them. This becomes useful when you recruit a co-founder, explain your progress to an incubator, or prepare for fundraising. Investors do not need a story about how exciting the hackathon was. They need to see how you moved from an assumption to a repeatable learning process.
Make discovery a founder habit after college
Student founders often have strong access to builders and limited access to buyers. That imbalance can make product work feel more productive than customer work. Resist it. Your code, design, and pitch only matter when they solve a problem that someone is willing to change behaviour, time, or budget to address.
Build a weekly rhythm that keeps you close to users. Reserve time for conversations, product observation, prototype tests, and follow-ups before you fill the calendar with events. As you gain traction, the questions will change: who pays, who uses, who blocks adoption, what makes retention possible, and where unit economics break. The habit stays the same: investigate before you assume.
At Nebula, we work as a venture builder in Tamil Nadu, building for India. We co-build alongside founders across validation, product, fundraising, and go-to-market, with embedded operators and outcome-tied economics. Our three-phase process moves from venture validation through product development to go-to-market and scale, because a strong company needs evidence at every stage.
Your next hackathon can give you a prototype, a team story, and a prize. Use it to earn something harder to copy: a precise understanding of a customer’s problem and a direct path to test whether your team should keep building.
Do not leave your hackathon with only a GitHub repository and a certificate. Leave with user notes, follow-up commitments, and one decision you can test in the next week. If you are ready to turn that evidence into a fundable company, Apply for Nebula 1.0.
Enjoyed this? Get the next one in your inbox.
Fundraising guides and validation frameworks, every two weeks. No spam.
Frequently asked questions
How many customer interviews should student founders run during a hackathon?
Set a realistic target based on access, then focus on people in the same user group. Detailed conversations about recent behaviour are more useful than many shallow opinions.
Should a student founder build a full app at a hackathon?
No. Build the smallest prototype that tests your biggest uncertainty, such as whether a user will complete a workflow or trust a proposed output.
What should student founders do after a hackathon?
Follow up within 48 hours, organise interview notes, choose one measurable learning goal, and run a focused four-week test with potential users.
Ready to build your startup?
We work with a small number of founders each year — mentorship, fundraising support, and a co-founder network included.
Start a conversation
Talk to the founder directly. We reply within two working days.
Applying to Nebula 1.0? Apply here →