21. Legal & Business: The Stuff Nobody Talks About But Everyone Should
You just built something amazing at a hackathon. Your team is pumped, you’re already thinking about launching, and maybe someone even asked if you’d turn this into a startup. But before you get carried away, there’s a bunch of legal and business stuff you need to think about. It’s not the most exciting part of hackathons, but ignoring it can create serious problems down the road.
This section covers everything you need to know about the legal and business side of hackathon projects. We’ll keep it practical and actionable because nobody wants to read a law textbook.
IP Ownership: Who Owns What You Build at a Hackathon?
This is the question that trips up most teams. The answer depends on a few factors, and it’s not always what you think. IP ownership is one of those things that doesn’t matter until it matters a lot—usually when your project becomes successful or when someone wants to invest in it.
The General Rule: If you build it on your own time with your own resources, you own it. But hackathons complicate this because you’re often using sponsor-provided resources, APIs, or platforms. The general rule is that whoever creates the work owns it, but there are exceptions that can override this.
Read the Fine Print: Every hackathon has terms and conditions. Some hackathons require you to assign IP rights to the organizer. Others let you keep ownership but give the sponsor a license to use your project. Some are completely hands-off and let you keep everything. The terms are usually in the registration paperwork or on the hackathon website. Most people click “I agree” without reading them. Don’t be most people.
Specific Scenarios:
- Personal hackathon: You own everything, assuming you didn’t use company resources. This is the cleanest scenario. You built it on your own time, with your own computer, using your own accounts. Nobody else has a claim.
- Corporate hackathon: Your employer likely owns it because you built it during work hours or with work resources. Many companies have policies that state anything you build during work hours belongs to them. Check your employment contract before the hackathon.
- Sponsored hackathon: Check if the sponsor has any claims on your IP. Sponsors often require a license to use your project for marketing purposes. Some sponsors go further and require IP assignment, meaning they own your project entirely.
- University hackathon: Your school might have a claim, especially if you used their facilities or equipment. Universities often have IP policies that cover student work, particularly if it was created using university resources.
The Smart Move: Before the hackathon starts, clarify ownership with the organizers. Get it in writing if possible. Most hackathons are pretty clear about this in their terms, but if they’re not, ask. Send an email to the organizers: “Can you confirm that teams retain IP ownership of their projects?” A simple email can save you headaches later.
Documentation Matters: Keep records of when you started and stopped working on the project. Save your git commits, design documents, and any other evidence of your work. If there’s ever a dispute about ownership, this documentation can be crucial. The hackathon’s start and end times serve as a natural documentation of when the work was done.
Sponsors provide prizes, APIs, food, and sometimes even mentors. But they’re not doing it out of the goodness of their hearts. They want something in return, and you need to know what you’re signing up for. Understanding sponsor terms is like reading the fine print on a cell phone contract—it’s tedious but important.
Common Sponsor Terms:
- License to use your project - They can showcase it in marketing materials. This is usually harmless and actually good for you—it gives your project exposure. But read the scope of the license. Is it limited to this hackathon’s marketing, or can they use it forever?
- Right of first refusal - If you want to commercialize it, they get first shot at investing. This isn’t necessarily bad, but it can limit your options. If you want to take VC money from a competitor, this could be a problem.
- Data access - They might want access to usage data from your project. This is common for API sponsors who want to understand how developers use their platform. Make sure you’re comfortable sharing this data.
- Attribution requirements - You might need to credit them in your project. Usually this is just “Built with [Sponsor] API” or similar. It’s a small price to pay for free API access.
- Exclusivity clauses - You might be restricted from using competing platforms. This is the most restrictive term and the one to watch out for. If you’re building a cloud-based project, an exclusivity clause might prevent you from using AWS if the sponsor is Azure.
What to Watch For:
- Overly broad language - “Perpetual, irrevocable, worldwide license” is a red flag. This means they can use your project forever, everywhere, and you can’t revoke the license. Most sponsors don’t need this level of access.
- Hidden fees - Some sponsors will let you use their API for free during the hackathon but charge you afterward. If your project uses an API that costs money after the hackathon, you need to know that before you build on it.
- Non-compete clauses - Some sponsors don’t want you building competing products. If you’re building something in a specific space, check if the sponsor has restrictions that would prevent you from continuing after the hackathon.
- Automatic IP assignment - This means they own your project, not just have a license. This is rare but it happens. If you see language about “assignment of rights” or “transfer of ownership,” pay attention.
The Reality: Most hackathon sponsors are reasonable. They want good PR and to attract developers to their platform. But you should still read the terms carefully and ask questions if something seems off. The organizers are usually happy to clarify any confusing language. Don’t be embarrassed to ask—there are no stupid questions when it comes to legal terms.
Questions to Ask Sponsors:
- “Can you explain what rights you’re requesting over our project?”
- “Are there any costs associated with using your API after the hackathon?”
- “Can we use competing services alongside yours?”
- “What happens to our project if we want to commercialize it later?”
Team Agreements: Simple Contract for Who Owns What
If you’re building with other people, you need to decide how ownership works. This is especially important if your project becomes successful and someone leaves the team. The time to have this conversation is before you start building, not after you’ve made money.
The Basic Questions:
- Is ownership split equally among all team members?
- What happens if someone doesn’t contribute as much?
- What if someone wants to leave the team?
- Who gets to make decisions about commercializing the project?
- What if two team members disagree about the direction?
- How are profits distributed if the project makes money?
- Who has authority to make legal decisions on behalf of the project?
A Simple Framework:
- Equal ownership with vesting - Everyone owns an equal share, but it vests over time (e.g., 4 years with 1-year cliff). This is the standard startup model and it’s fair because it rewards commitment. If someone leaves after 6 months, they don’t get a full share.
- Contribution-based ownership - Ownership is proportional to contribution. This makes sense for hackathons where some people might contribute significantly more than others. The challenge is defining what “contribution” means—code? Design? Business planning?
- Lead developer gets majority - The person who did the most technical work gets the largest share. This is common in hackathons where one person drives the technical implementation. It can create tension if other team members feel undervalued.
- Company structure - Form an LLC or corporation and distribute shares officially. This is the most professional approach and the one to use if you’re serious about turning the project into a business. It also provides liability protection and makes it easier to bring on investors.
The Conversation to Have: Before you start building, sit down with your team and talk about ownership. It’s awkward, but it’s way more awkward to have this conversation after you’ve made money. Here’s a script: “Hey, before we start building, let’s talk about ownership. If this project succeeds, how should we split the rewards? I want to make sure we’re all on the same page.”
The Written Agreement: Even if you’re best friends, put your agreement in writing. It doesn’t have to be a formal legal document—a shared Google Doc with everyone’s signatures is fine for a hackathon project. Include:
- Ownership percentages
- Vesting schedule (if applicable)
- Decision-making process
- What happens if someone wants to leave
- What happens if the project is sold
Real-World Example: Here’s a simple team agreement template:
“We, the undersigned, agree that ownership of the project [Project Name] built at [Hackathon Name] on [Date] is distributed as follows:
All team members agree to the following:
- Decisions about the project will be made by majority vote
- If a team member wants to leave, they retain their ownership percentage
- If the project is sold, profits will be distributed according to ownership percentages
- All team members will be credited as co-founders
Signed: [All team members with dates]”
This is simple, clear, and covers the basics. You can always make it more formal later if the project becomes serious.
Open Source Licensing Decisions: MIT vs. Apache vs. GPL
If you’re planning to open source your hackathon project, you need to pick a license. Each one has different implications, and choosing the wrong one can limit your options later. This isn’t a decision to make lightly—once you release code under a specific license, you can’t take it back.
MIT License:
- Pros: Simple, permissive, widely understood. Anyone can use, modify, and distribute your code with minimal restrictions. It’s the most popular open source license for a reason.
- Cons: No patent protection, no requirement to share modifications. Someone can take your code, modify it, and release it as proprietary software without contributing back.
- Best for: Simple projects, libraries, and tools. If you want maximum adoption and don’t care about derivatives being closed source, MIT is the way to go.
Apache License 2.0:
- Pros: Patent protection, allows proprietary use, well-understood. The patent grant is important—it protects users from patent lawsuits related to your code.
- Cons: More complex than MIT, requires attribution. You need to include the license and copyright notice in your distribution.
- Best for: Projects you want to be widely adopted, enterprise use. If you’re building something that companies might want to use in their products, Apache is a safer choice than MIT.
GPL v3:
- Pros: Ensures all derivatives are also open source, strong copyleft. If someone uses your code in their project, they have to release their entire project under GPL.
- Cons: Can scare off commercial use, viral licensing. Many companies have policies against using GPL code because of the copyleft requirement.
- Best for: Projects where you want to ensure the code stays open. If your primary goal is to keep the code free and open, GPL is the strongest option.
The Hackathon Reality: For most hackathon projects, MIT is the safe choice. It’s simple, permissive, and doesn’t create headaches. If you’re building something with potential commercial value and you want to keep options open, Apache is better. Don’t use GPL for hackathon projects unless you specifically want to ensure all derivatives are open source—it can limit your options if you want to commercialize later.
Other Options: There are dozens of other licenses (BSD, MPL, LGPL, etc.), but for hackathon projects, these three cover 99% of use cases. Don’t overthink it—pick the one that aligns with your goals and move on.
Pro Tip: If you’re not sure, MIT is almost always the right answer for hackathon projects. It’s permissive, simple, and widely understood. You can always change your license later by releasing a new version under a different license (you can’t retroactively change the license for code already distributed, but you can release new versions under different terms).
Common Mistakes:
- Picking GPL because it’s “more open” - GPL has restrictions that can limit your project’s adoption
- Not including a LICENSE file - Without a license file, your code is not actually open source
- Mixing licenses - If you use code from other projects, make sure their licenses are compatible with yours
- Forgetting about dependencies - Your project’s license might conflict with the licenses of your dependencies
Post-Hackathon IP Rights: Can You Turn It Into a Startup?
Yes, you absolutely can. Many successful startups were born at hackathons. But there are some things you need to think about before you quit your day job and go all in. The transition from hackathon project to startup is more complex than most people realize.
Legal Considerations:
- Verify ownership - Make sure you actually own the IP before investing time and money. This sounds obvious, but you’d be surprised how many teams start building a business without confirming they own the code. Check the hackathon terms, check your employment contracts, and check any agreements you signed.
- Check for conflicts - If you built this during work hours or with company resources, your employer might have a claim. Even if you used your personal laptop, if you did it during work hours, your employer might argue they own it. Review your employment contract carefully.
- Review sponsor terms - Make sure there are no restrictions on commercialization. Some sponsors have clauses that prevent you from competing with them or that give them a stake in your project. Understand these terms before you invest time and money.
- Protect your trademark - If your project name is valuable, trademark it. Trademark registration costs a few hundred dollars and prevents others from using your name. Do this before you announce your startup publicly.
Business Considerations:
- Validate the idea - Just because it won a hackathon doesn’t mean it’s a viable business. Hackathon judges are evaluating a prototype, not a market. You need to validate that people will actually pay for this. Talk to potential customers, run surveys, and test your assumptions.
- Find co-founders - If your hackathon team isn’t interested in starting a company, find people who are. A hackathon team is different from a founding team. You need people who are committed for the long haul, not just for a weekend.
- Build a proper product - A hackathon MVP is not a production-ready product. It’s a demo that works under controlled conditions. A real product needs error handling, security, scalability, and support. Budget 3-6 months to turn your hackathon prototype into something you can actually sell.
- Get funding - Hackathon prizes aren’t enough to build a real company. You’ll need to raise money or bootstrap. Most hackathon projects that become successful startups raise seed funding within 6-12 months of the hackathon.
The Timeline: Most hackathon-to-startup success stories took 6-12 months to go from hackathon project to funded startup. Don’t rush it, but don’t let momentum die either. The key is to keep building, keep talking to users, and keep refining your idea. The hackathon is just the beginning.
Success Stories: Some well-known startups that started at hackathons include GroupMe (built at a hackathon, acquired by Skype for $80 million), Jetpac (built at a hackathon, acquired by Google), and Shipt (built at a hackathon, acquired by Target for $550 million). These aren’t just stories—they’re proof that hackathon projects can become real businesses.
Privacy Considerations: If Your Project Handles User Data
Even if you built your project in 36 hours, you still need to think about privacy. This is especially important if your project collects, stores, or processes user data. Privacy isn’t just a legal requirement—it’s an ethical obligation to the people who trust you with their information.
The Basics:
- Collect only what you need - Don’t ask for information you don’t actually use. If your project doesn’t need someone’s phone number, don’t ask for it. Every piece of data you collect is a liability.
- Be transparent - Tell users what you’re doing with their data. A simple privacy policy that explains what you collect, how you use it, and who you share it with is sufficient for most hackathon projects.
- Secure storage - Use encryption and secure databases, even for prototypes. If you’re storing user data in a public GitHub repo or an unsecured database, you’re putting your users at risk.
- No sharing - Don’t sell or share user data with third parties. This is a fast way to lose trust and get into legal trouble.
- Right to delete - Let users delete their data if they want. This is a legal requirement in many jurisdictions and a basic courtesy.
Regulatory Requirements:
- GDPR (Europe) - If you have European users, you need to comply. GDPR is strict and the penalties are severe. You need to get explicit consent before collecting data, allow users to access and delete their data, and report data breaches within 72 hours.
- CCPA (California) - If you have California users, you need to comply. CCPA gives California residents the right to know what data you collect, the right to delete it, and the right to opt out of its sale.
- COPPA (Children) - If your project is for children under 13, you need special protections. COPPA requires parental consent before collecting data from children, and the penalties for violations are significant.
- HIPAA (Healthcare) - If you’re handling health data, you need strict compliance. HIPAA is complex and unforgiving. If your project touches health data in any way, consult a lawyer before launching.
The Hackathon Reality: Most hackathon projects don’t need to worry about full regulatory compliance. But you should still follow basic privacy principles. If you’re serious about commercializing your project, invest in proper privacy compliance before launch. The cost of compliance is much less than the cost of a data breach or regulatory fine.
Practical Steps for Hackathon Projects:
- Add a simple privacy policy to your project (even a one-pager is better than nothing)
- Don’t collect data you don’t need
- If you’re using a database, make sure it’s not publicly accessible
- If you’re using third-party services, check their privacy practices
- If you’re storing sensitive data, encrypt it
The Cost of Ignoring Privacy: Data breaches can cost millions of dollars in fines, legal fees, and reputational damage. Even if your hackathon project is just a prototype, if you’re handling user data, you have a responsibility to protect it. Don’t let a weekend project turn into a year-long legal nightmare.
Terms of Service Basics: What to Include in Your MVP
Even if your project is just a hackathon prototype, if it’s going to be used by other people, you need basic terms of service. Terms of service protect you from liability and set clear expectations with your users. They’re not just legal boilerplate—they’re a communication tool that tells users what they can expect from your project.
The Minimum Viable ToS:
- What the service does - Brief description of functionality. Tell users what your project does and what they can expect. Don’t oversell it—if it’s a prototype, say so.
- User responsibilities - What users can and can’t do. Can they use it commercially? Can they share it? Can they reverse engineer it? Set clear boundaries.
- Data handling - What you collect and how you use it. Even a simple statement like “We don’t collect any personal data” is better than nothing.
- Limitation of liability - You’re not responsible for damages. This is standard boilerplate that protects you from lawsuits. Something like “This project is provided as-is without warranty of any kind” is sufficient.
- Termination - When and how you can end access. You should reserve the right to terminate access at any time, for any reason. This gives you flexibility if something goes wrong.
- Contact information - How users can reach you. Include an email address or other contact method so users can reach you with questions or concerns.
The Simple Version: For a hackathon project, keep it short and simple. You don’t need a 50-page legal document. A clear, concise ToS that explains the basics is enough. Here’s a template:
“Terms of Service
By using [Project Name], you agree to the following terms:
- This project is provided as-is without warranty of any kind.
- We are not responsible for any damages that may result from using this project.
- We reserve the right to modify or terminate this service at any time.
- You agree to use this project only for lawful purposes.
- We may collect usage data to improve our service.
Contact: [email@address.com]
Last updated: [Date]”
That’s it. It’s not perfect, but it’s better than nothing and it covers the basics.
Where to Get Help: Use online ToS generators for basic templates, or ask a lawyer friend to review your draft. Don’t just copy someone else’s ToS because it might not apply to your specific situation. There are free tools like TermsFeed and PrivacyPolicies.com that can help you generate basic terms.
When You Need More: If your project handles sensitive data, involves financial transactions, or is being used commercially, you need a more comprehensive ToS. Consider consulting a lawyer at that point. The cost of a lawyer is much less than the cost of a lawsuit.
Data Handling: What to Do with User Data After the Hackathon
This is the part most teams forget about. The hackathon is over, but what happens to the data you collected? This is a real responsibility that many teams ignore because they don’t think it matters. It does. If you collected user data, you have an obligation to handle it responsibly, even if your project never goes anywhere.
Immediate Actions:
- Export your data - Make sure you have backups of everything. Don’t rely on hackathon-provided infrastructure that might be decommissioned after the event. Download your database, export your logs, and save everything locally.
- Review what you collected - Do you actually need all of it? If you collected email addresses for testing purposes and don’t need them anymore, delete them. The less data you have, the less liability you carry.
- Secure storage - Move data from hackathon accounts to proper storage. If you’re using a sponsor’s API or database, export your data and move it to your own secure storage. Don’t leave data sitting on accounts you don’t control.
- Delete what you don’t need - Don’t keep data “just in case.” If you don’t have a specific reason to keep data, delete it. This is both a privacy best practice and a liability reduction strategy.
Long-term Considerations:
- Data retention policy - How long will you keep the data? If you’re not planning to use the data anymore, delete it. If you’re keeping it for a specific purpose, document that purpose and set a deletion date.
- Deletion process - How will users delete their data if they want? If you collected user data, you need a way for users to request deletion. This can be as simple as an email address where users can send deletion requests.
- Third-party services - Are you using any services that have access to your data? If you’re using Google Analytics, Mixpanel, or any other third-party service, check their data retention policies. They might be keeping your data longer than you realize.
- Breach notification - What happens if your data gets compromised? If you’re holding user data, you need a plan for notifying users if that data is breached. This is a legal requirement in many jurisdictions.
The Reality: If your hackathon project collected any user data, you have a responsibility to protect it. Even if the project never goes anywhere, you need to handle the data responsibly. Delete what you don’t need, secure what you keep, and be transparent with users.
A Practical Checklist:
The Consequence of Neglect: If you ignore data handling, you’re not just being irresponsible—you’re creating legal liability. If a user’s data is breached because you didn’t secure it properly, you could be held responsible. If you collected data without proper consent, you could face regulatory fines. Take data handling seriously, even for hackathon projects.
Some hackathons require you to sign NDAs (Non-Disclosure Agreements), especially if the sponsor is sharing proprietary information or APIs. This is common at corporate hackathons where the sponsor is giving you access to unreleased technology or sensitive business information. Understanding what you’re signing is crucial.
When NDAs Make Sense:
- Proprietary APIs - If the sponsor is giving you access to unreleased technology, they need to protect that information. An NDA ensures you don’t share their proprietary API with competitors.
- Sensitive business information - If you’re learning about their internal processes, they need to protect that information. An NDA prevents you from sharing their business strategies with others.
- Competitive information - If they’re sharing data that could help competitors, they need to protect it. An NDA prevents you from using their data to help their competitors.
When NDAs Are Red Flags:
- Overly broad scope - “You can’t discuss anything you see here” is unreasonable. A reasonable NDA should specify what information is confidential, not blanket everything you see.
- Unlimited duration - NDAs should have an expiration date. An NDA that lasts forever is unreasonable and potentially unenforceable. Standard NDA durations are 1-3 years.
- No carve-outs - You should be able to discuss your own project. If the NDA prevents you from talking about what you built, that’s a problem. You need to be able to present your project to judges and talk about it publicly.
- One-sided terms - The sponsor should also have obligations. A one-sided NDA that only restricts you while giving the sponsor free rein is not a fair agreement.
The Smart Approach: Read the NDA carefully. If it’s reasonable, sign it. If it seems overly restrictive, ask questions. Most hackathon NDAs are standard and fair, but you should still understand what you’re agreeing to. Here are some questions to ask:
- “Can we discuss our project publicly after the hackathon?”
- “What specific information is considered confidential?”
- “How long does the NDA last?”
- “Are there any exceptions for our own project?”
What to Do If You’re Uncomfortable: If the NDA seems unreasonable, talk to the organizers. Explain your concerns and ask if they can modify the terms. Most organizers are flexible and willing to work with you. If they’re not, consider whether you want to participate in that hackathon. The prize might not be worth the legal restrictions.
The Reality: Most hackathon NDAs are reasonable and designed to protect the sponsor’s proprietary information while allowing you to build and present your project. Don’t be paranoid about NDAs, but don’t blindly sign them either. Understand what you’re agreeing to and make an informed decision.
“Built at a Hackathon” Disclaimer: When and How to Use It
If you’re presenting your hackathon project publicly or commercially, you might want to include a disclaimer. This sets expectations and gives proper credit. A well-crafted disclaimer can actually enhance your credibility by showing that you’re transparent about the project’s origins.
When to Use It:
- Commercial presentations - If you’re pitching to investors or customers, let them know this was built in a weekend. It manages expectations about polish and completeness.
- Public demos - If you’re showing it at meetups or conferences, acknowledge the hackathon context. It gives the audience context for the project’s scope and ambition.
- Job applications - If you’re showing it in your portfolio, credit the hackathon and your team. It shows that you can build things quickly under pressure.
- Open source projects - If you’re releasing it publicly, document the hackathon origins. It gives users context for the project’s maturity level.
What to Include:
- Hackathon context - “Built at [Hackathon Name] in [X] hours” tells people the constraints you were working under. It’s actually impressive that you built something this good in such a short time.
- Team credit - “Built by [Team Members]” gives credit where it’s due. It’s professional and respectful to acknowledge everyone who contributed.
- Sponsor acknowledgment - “Using [Sponsor] API/platform” credits the resources that made it possible. It’s also good practice for maintaining relationships with sponsors.
- Status disclaimer - “This is a prototype, not a production-ready product” sets expectations. It tells people not to expect enterprise-grade security or reliability from a weekend project.
The Purpose: A disclaimer sets expectations. It tells people that this was built under time constraints and might not be fully polished. It also gives credit to the hackathon and sponsors who made it possible. Most importantly, it shows that you’re honest and transparent about the project’s origins.
Example Disclaimer:
“Built at [Hackathon Name] in 36 hours by [Team Names]. This is a prototype created during a hackathon and is not a production-ready product. Built using [Sponsor] API and [Other Technologies]. For questions, contact [email].”
Where to Put It: Include the disclaimer in your README, on your landing page, and in any presentations. If you’re demoing at a meetup, mention it verbally. If you’re submitting to an accelerator or incubator, include it in your application.
The Bottom Line: Legal and business stuff isn’t the most exciting part of hackathons, but it’s important. Taking care of these details early prevents problems later. You don’t need to be a lawyer, but you need to be informed and make smart decisions.
Legal Checklist for Hackathon Projects
Here’s a quick checklist you can use during and after the hackathon:
Before the Hackathon:
During the Hackathon:
After the Hackathon:
If You’re Commercializing:
Now go build something amazing and make sure you actually own it when you’re done.