Entregue um produto e arquitetura em 48h (sem drama)

Press enter or click to view image in full size

Todo hackathon começa igual: café, pizza, post-it e a promessa do “vamos mudar o mundo no fim de semana”.

Eu adoro a energia. Mas como mentor e jurado, já vi muito projeto morrer na segunda-feira, não por falta de ideia, e sim por falta de pensamento de produto e arquitetura minimamente intencional. Fizeram “funcionar” e esqueceram de fazer sentido.

Meu convite: Usar as 48h como simulador de startup. Você joga como dev, produto e tech lead, ao mesmo tempo.

Hackathon ≠ prova de código. É simulação de produto.

Erro clássico: time entra em “modo vestibular”.

“Vamos provar que sabemos React, Node, Kubernetes e três buzzwords novas.”

Sai um Frankenstein: Mil techs, zero narrativa.

Reality check do John: Hackathon é uma startup acelerada:

• Problema (mal explicado, quase sempre);
• Pouco tempo e recurso;
• Escolhas técnicas e de produto;
• E no final alguém pergunta: “É viável, escala e fecha conta?”.

Regra de bolso: O júri não premia complexidade, premia convicção: técnica + negócio + execução conversando.

Primeiras 2 horas: decidir o que não fazer

Time iniciante “abraça o mundo”. Time maduro corta escopo sem dó.

Roteiro prático (120 min):

Brutalidade de foco

Qual dor real? Quem sente? Como resolve hoje?

Recorte cirúrgico

Nada de “plataforma completa de…”.
Pegue um pedaço específico, feito de ponta a ponta.

Pitch técnico em 3 frases

• Problema: Lojistas perdem venda por resposta lenta no WhatsApp.
• Solução: Dashboard que centraliza mensagens e sugere respostas.
• MVP técnico: 1 API de mensagens, 1 worker de sugestão, 1 tela funcional.

Se não cabe em 3 frases, sua arquitetura vai virar ruído.

Stack em hackathon: Menos ego, mais entrega

Hackathon não é laboratório de microserviço. Não brinque de Event Sourcing em 48h.

Checklist da stack:

• Domínio do time: 2+ pessoas já mexem? Ganhou 1 ponto.
• Velocidade de protótipo: frameworks opinativos (Rails, Laravel, Django, Nest) brilham aqui.
• Arquitetura explicável em 1 slide: se precisa de 10 caixas e 3 filas pro fluxo principal, complicou.

Desenho que passa no meu crivo:

Sentiu falta de 20 coisas? Ótimo: Fica para o pós-hackathon (se for adiante).

Arquitetura de MVP: o mínimo que aguenta a demo

MVP não é gambiarra que só roda no notebook, nem “enterprise deluxe”.

É intencionalmente simples e consistente o suficiente pra não quebrar ao vivo.

O que eu procuro (lado técnico):

• Fluxo principal ponta a ponta: usuário entra → faz ação core → vê resultado.
• Separação mínima de camadas: rota → controlador → serviço → dados.
• Pontos de extensão claros: onde plugar auth séria, outro pagamento, outro provider?

Pseudo-exemplo (Node/Express):

// routes/orders.js
router.post('/', orderController.createOrder);

// controllers/orderController.js
exports.createOrder = async (req, res) => {
const order = await orderService.create(req.body);
res.status(201).json(order);
};

// services/orderService.js
exports.create = async (data) => {
const order = await orderRepository.save(data);

// TODO: faturar, enviar e-mail, etc. (pontos de extensão)
return order;
};

Simples, porém intencional. E o jurado percebe.

O que um jurado técnico enxerga em minutos

Sem code review linha a linha. Eu olho para:

• Confiabilidade da demo: Se precisa abrir 7 abas e dar F5 rezando, já entendi.
• Arquitetura mínima: Divisão de responsabilidades existe?
• Dados com noção: Chaves claras; Nada pendurado em “variáveis mágicas” num JSON solto.
• Integrações sinceras: Pode mockar, desde que declare e mostre qual seria o endpoint real.
• Porquê da stack: “Usamos X porque dominamos e evoluímos depois”, muito melhor do que “é hype”.

Feature x estabilidade x narrativa (ordem importa)

Mataram em features e nenhuma fica redonda? Perdeu.

Priorize:

• Fluxo principal funcional (o “existe” da sua solução).
• Estabilidade demo-friendly: Nada de feature nova a T-30 min.
• Narrativa amarrada: Quem fala o quê, quando mostra tela, quem explica arquitetura.

Script de pitch (60–90s):

“Atacamos [problema X] com um fluxo simples: [frase curta].
Tecnicamente, usamos [stack Y] porque [razão do time/velocidade].
Arquiteturalmente, [monolito bem organizado / API + frontend], com pontos de extensão pra [integrações futuras].
Em 48h, priorizamos [fluxo principal + estabilidade] em vez de inflar features.”

Maturidade pesa.

Checklist do próximo hackathon (printa e leva)

Antes de codar

• Problema em 2–3 frases.
• Recorte do pedaço que vamos resolver.
• Stack alinhada ao que o time domina.

Início da implementação

• Diagrama simples (3–5 caixas).
• User story principal definida.
• Camadas mínimas separadas (rota → controller → service → dados).

Metade do evento

• Fluxo principal funcional (mesmo feio).
• Testes com dados diferentes e caminhos alternativos.
• Lista dos mocks pra explicar no pitch.

Reta final

• Foco na estabilidade (sem refactor pesado).
• Ensaiar pitch com 1 slide de arquitetura.
• Definir quem responde perguntas técnicas.

Além do hackathon: pensar como dev de produto (desde já)

Os projetos que ficam não são os mais “bonitos”; são os implementáveis, com decisões conscientes e rampa de evolução sem jogar tudo fora.

Trate cada hackathon como laboratório de decisão técnica rápida. Você comprime anos de cicatriz em 48 h.