> 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/hackathon/common-mistakes.md).

# Erros Comuns para Evitar

Você estudou todo esse guia e está se preparando para entrar com tudo no hackathon Frontier da Solana. Você montou seu time de builders com programadores, designers e marketeiros. Você estocou sua cozinha com miojo e energéticos.

Mas antes de começar, vamos falar sobre como evitar algumas armadilhas muito comuns. Através de dolorosas tentativas e erros, a comunidade da Solana extraiu princípios-chave sobre como **NÃO** desperdiçar seu tempo limitado de construção.

## Armadilha 1: Resolvendo um problema "falso"

Os projetos mais bem-sucedidos resolvem problemas reais que pessoas ou empresas reais enfrentam hoje. Concentre-se em atender necessidades que já existem em vez de evocar necessidades falsas.

**Como evitar:**

* Baseie seu projeto em problemas práticos reais. Uma excelente declaração de problema pode levar seu projeto ao final mesmo com solução imperfeita.
* Converse com usuários reais para identificar pontos problemáticos. Não confie em suposições.
* Considere áreas como onboarding de usuários, UX de varejo, privacidade, identidade e infraestrutura.
* Evite ideias que pareçam interessantes, mas não tenham problema claro e urgente por trás.

## Armadilha 2: Ignorar os pontos fortes de Solana

Os jurados procuram projetos que destaquem os pontos fortes de Solana. Aproveite ao máximo as transações baratas e rápidas. Mostre conectividade com carteiras móveis. Demonstre como Solana desbloqueia experiências que não funcionariam em outras blockchains.

**Como evitar:**

* Aproveite especificamente velocidade, taxas baixas e outros pontos fortes da Solana.
* Estude o que faz a Solana ser única e construa em torno desses recursos.
* Não envie ideias genéricas que possam funcionar em qualquer blockchain.

## Armadilha 3: Não demonstrar seu progresso

Mesmo que seu demo não esteja perfeito, mostre algo funcional. Um app ao vivo, mesmo limitado, prova progresso muito mais do que slides.

**Como evitar:**

* Construa em público. Compartilhe progresso nas redes sociais e comunidades Solana.
* Documente sua jornada no Twitter ou blog. Busque feedback da comunidade.
* Participe de eventos Solana para networking e visibilidade.

## Armadilha 4: Improvisar a apresentação

Grandes apresentações não acontecem espontaneamente. Exigem prática. Faça perguntas difíceis a si mesmo, cronometre sua apresentação e obtenha feedback dos colegas.

**Como evitar:**

* Priorize um demo funcional com bom UI. Juízes querem funcionalidades tangíveis.
* Construa um MVP que funcione de ponta a ponta, mesmo incompleto.
* Demo ao vivo > vídeo chamativo.
* Não gaste todo o tempo em design — construa e teste a solução real.

## Armadilha 5: Ausência de um plano de negócios

Os jurados sabem que mesmo ideias incríveis não levam a lugar nenhum sem modelo de negócios viável. Pense em como gerar receita, reter usuários e expandir.

**Como evitar:**

* Estruture apresentações em torno de funcionalidades detalhadas, não apenas vídeos promocionais.
* Evite chavões e exageros. Mostre aplicação prática e utilidade.
* Esteja preparado para responder perguntas detalhadas sobre como funciona por baixo do capô.
* Impressione com substância, não estilo — demos reais em vez de afirmações ousadas.


---

# 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:

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

The question should be specific, self-contained, and written in natural language.
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.