> For the complete documentation index, see [llms.txt](https://wiki.superteam.com.br/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.superteam.com.br/en/hackathon/common-mistakes.md).

# Common Mistakes to Avoid

You've studied this entire guide and are getting ready to go all in on the next Solana global hackathon. You've assembled your builder team with programmers, designers, and marketers. You've stocked your kitchen with instant noodles and energy drinks.

But before you start, let's talk about how to avoid some very common pitfalls. Through painful trial and error, the Solana community has distilled key principles about how **NOT** to waste your limited build time.

## Pitfall 1: Solving a "Fake" Problem

The most successful projects solve real problems that real people or businesses face today. Focus on addressing needs that already exist rather than conjuring up fake ones.

**How to avoid:**

* Base your project on real, practical problems. An excellent problem statement can carry your project to the finals even with an imperfect solution.
* Talk to real users to identify pain points. Don't rely on assumptions.
* Consider areas like user onboarding, retail UX, privacy, identity, and infrastructure.
* Avoid ideas that seem interesting but don't have a clear, urgent problem behind them.

## Pitfall 2: Ignoring Solana's Strengths

Judges look for projects that highlight Solana's strengths. Make the most of cheap and fast transactions. Show connectivity with mobile wallets. Demonstrate how Solana unlocks experiences that wouldn't work on other blockchains.

**How to avoid:**

* Specifically leverage Solana's speed, low fees, and other strengths.
* Study what makes Solana unique and build around those features.
* Don't submit generic ideas that could work on any blockchain.

## Pitfall 3: Not Demonstrating Your Progress

Even if your demo isn't perfect, show something functional. A live app, even a limited one, proves progress far more than slides.

**How to avoid:**

* Build in public. Share progress on social media and Solana communities.
* Document your journey on Twitter or a blog. Seek feedback from the community.
* Attend Solana events for networking and visibility.

## Pitfall 4: Improvising the Presentation

Great presentations don't happen spontaneously. They require practice. Ask yourself tough questions, time your presentation, and get feedback from peers.

**How to avoid:**

* Prioritize a functional demo with good UI. Judges want tangible features.
* Build an MVP that works end-to-end, even if incomplete.
* Live demo > flashy video.
* Don't spend all your time on design — build and test the actual solution.

## Pitfall 5: Lack of a Business Plan

Judges know that even incredible ideas go nowhere without a viable business model. Think about how to generate revenue, retain users, and scale.

**How to avoid:**

* Structure presentations around detailed features, not just promotional videos.
* Avoid buzzwords and hype. Show practical application and utility.
* Be prepared to answer detailed questions about how it works under the hood.
* Impress with substance, not style — real demos instead of bold claims.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://wiki.superteam.com.br/en/hackathon/common-mistakes.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.