Os 22 Axiomas do Go Unicorn

As leis imutáveis do eXtreme Go Unicorn (XGU). Memorize. Pratique. Faça IPO.

Os axiomas do Go Unicorn são verdades absolutas. Não são sugestões. Não são guidelines. São leis da natureza do desenvolvimento de software em startups. Assim como a gravidade, você pode ignorá-los, mas vai cair.

Axioma 1 — Pensou, já é XGU. Pensou demais, não é mais.

No XGH não se pensa. No XGU, você pensa por exatamente 5 segundos. Esse é o tempo ótimo entre “agir sem pensar” e “virar um arquiteto Java enterprise dos anos 2000 que gasta 6 meses desenhando diagramas UML”.

5 segundos. Nem mais, nem menos.

Axioma 2 — Existem infinitas formas de resolver um problema

A forma certa. A errada. A XGH. E a XGU — que é a errada, com um README bonito, um diagrama no Excalidraw, e um pitch deck de 12 slides.

Axioma 3 — MVW: Model, View, Whatever

A arquitetura oficial do XGU é MVW — Model, View, Whatever. O “Whatever” é a camada mais importante. É onde mora a lógica de negócio, as regras de validação, as chamadas de API, o CSS inline, os console.log, e a fé de que vai funcionar em produção.

O “Whatever” não é uma falha arquitetural. É flexibilidade estratégica.

Axioma 4 — Clean Code é indentação

Se o código está indentado, é Clean Code. Se as variáveis têm mais de 3 caracteres, é Clean Code avançado. Se você usa camelCase consistentemente, Robert C. Martin desce do céu e te abençoa.

O resto do livro é opcional.

Axioma 5 — DDD: Deadline Driven Design

Domain-Driven Design é lindo na teoria. Na prática, o Domain é definido pelo deadline da sprint. O Bounded Context é “o que dá pra entregar até sexta”. A Ubiquitous Language é “o que o PO falou no Slack às 18h de ontem”.

Aggregates, Value Objects, Repositories? São nomes bonitos pra classes, objetos, e queries SQL.

Axioma 6 — Clean Architecture é ter pastas bonitas

Se seu projeto tem /domain, /infrastructure, /application e /presentation, parabéns: você pratica Clean Architecture. O que tem dentro das pastas é irrelevante para o investidor.

src/
  domain/           # onde deveria estar a lógica
  application/      # onde realmente está a lógica
  infrastructure/   # onde está o resto da lógica
  presentation/     # onde está a gambiarra que conecta tudo

A estrutura de pastas é a arquitetura. O conteúdo é detalhe de implementação.

Axioma 7 — Todo unicórnio começa com um index.js de 3000 linhas

Microservices são para quem já captou a Series C. Você é pre-seed. Coloca tudo num arquivo só e chama de “monolito estratégico”. Se alguém questionar, diga que “estamos otimizando para velocidade de iteração e minimizando overhead de comunicação inter-serviços”.

É a mesma coisa que index.js de 3000 linhas, mas soa melhor.

Axioma 8 — Testes são para quem não acredita na própria visão

Steve Jobs não testava. Ele acreditava. Elon Musk testa em produção. Bezos testa nos clientes.

Mas escreva pelo menos um teste unitário. Pro investidor ver no CI/CD. Um. Só um. De preferência o mais simples possível:

test('app exists', () => {
  expect(true).toBe(true);
});

Build passing. Confiança técnica transmitida. Missão cumprida.

Axioma 9 — O README vale mais que mil páginas de docs

Ninguém lê wiki. Ninguém lê Confluence. Ninguém lê aquele Google Doc de 47 páginas que o tech lead escreveu.

Todo mundo lê um README com:

Badges coloridas (build, coverage, license)
Um GIF do produto funcionando
“Getting Started” de 3 linhas
Uma seção “Architecture” com um diagrama bonito

Se o README é bom, o software é bom. Correlação é causalidade no XGU.

Axioma 10 — XGU é orientado a pitch

No XGH, o código é orientado a gambiarra. No XGU, é orientado a pitch. Toda decisão técnica deve ser justificável em um slide de pitch deck.

“Por que usamos Kubernetes?” — Porque está no slide 7. “Por que Event Sourcing?” — Porque está no slide 9. “Por que essa tecnologia que ninguém conhece?” — Porque diferencial competitivo.

Axioma 11 — Refactoring é pivotar

No XGU não existe refactoring. Existe “pivotar a arquitetura”. É a mesma coisa, mas soa estratégico em reunião com investidor.

Reescrever do zero → “Pivotar a stack”
Mudar o banco de dados → “Migrar a camada de persistência”
Deletar metade do código → “Simplificar o domínio”
Dar up no server → “Escalar horizontalmente a infraestrutura”

Vocabulário é poder.

Axioma 12 — Design Patterns são para o Medium

Escreva um artigo no Medium sobre como você usa CQRS e Event Sourcing. Na codebase real, use if/else. O artigo gera tráfego e autoridade técnica. O if/else gera dinheiro e funcionalidade.

Os dois coexistem pacificamente. É XGU puro.

Axioma 13 — O prazo é a sprint. A sprint é o prazo.

No XGU, Agile não é metodologia — é estilo de vida.

A daily é onde você descobre o que deveria ter feito ontem
A sprint review é onde você mostra o que deu tempo de fazer
A retrospectiva é onde você promete o que não vai cumprir na próxima sprint
O backlog é o cemitério de boas intenções

Axioma 14 — Framework novo é diferencial competitivo

Se o investidor perguntar sua stack, você não pode dizer jQuery. Escolha o framework mais recente, mais hypado, mais instável. Se ele quebrar em produção, é “cutting edge technology com trade-offs aceitáveis”.

Se a documentação do framework está em chinês e tem 12 stars no GitHub, melhor ainda. First mover advantage.

Axioma 15 — A regra de negócio fica onde ela quiser

No Clean Architecture puro, a regra de negócio mora na camada de domínio. No XGU, ela mora onde o último dev que mexeu achou que deveria morar.

Controllers, views, migrations, .env, docker-compose.yml, comentários no Jira — todas são moradas válidas para regras de negócio no XGU.

Axioma 16 — Pair Programming é dividir a culpa

Se o código quebrou e dois escreveram, ninguém escreveu. Pair Programming é a forma mais sofisticada de diluir responsabilidade desde a invenção da sociedade anônima.

No XGU, Pair Programming também serve para justificar por que a task demorou o dobro: “Estávamos fazendo knowledge sharing”.

Axioma 17 — Documentação é o código em si

Se alguém precisa de documentação pra entender seu código, o problema é:

A pessoa (70% dos casos)
O código (25% dos casos)
O universo (5% dos casos)

De qualquer forma, a solução não é escrever documentação. É contratar alguém que entenda o código. Ou esperar o dev original voltar de férias. Ou reescrever do zero.

Axioma 18 — TypeScript é Clean Code automático

Só de usar TypeScript, seu código já é mais limpo que 90% dos projetos JavaScript do planeta. Se você usar any em menos de 50% dos tipos, é basicamente um projeto enterprise.

// Isso é Clean Code no XGU:
const data: any = await fetch(url).then((r: any) => r.json());

TypeScript: quando você quer os benefícios de tipagem sem o compromisso de realmente tipar.

Axioma 19 — Docker é arquitetura

Se roda no Docker, tem arquitetura. Se tem docker-compose, é microsserviços. Se tem Kubernetes, é Cloud Native. Se tem Terraform, é Infrastructure as Code.

O que roda dentro do container é detalhe de implementação. O investidor não abre o Dockerfile. Ele vê o diagrama de infraestrutura no pitch deck e fica impressionado.

Axioma 20 — Feature flag é débito técnico com nome bonito

Todo código morto no XGU é uma “feature flag desabilitada”. Todo bug é um “comportamento feature-flagged”. Toda gambiarra é uma “feature em soft launch”.

É Clean Code com visão de produto.

Axioma 21 — O XGU é cumulativo

Diferente do XGH que é anárquico e rejeita tudo, o XGU absorve qualquer metodologia. Scrum, Kanban, SAFe, Crystal, XP, Lean, Shape Up — tudo vira XGU. Como um buraco negro de boas intenções e buzzwords.

Você não precisa escolher entre XGU e outra metodologia. O XGU já inclui a outra metodologia. Ela só está… adaptada.

Axioma 22 — Se virou unicórnio, era XGU. Se não virou, era XGH.

A diferença entre XGU e XGH é puramente retrospectiva. Se a startup deu certo, sempre foi XGU. Se faliu, sempre foi XGH. O código é exatamente o mesmo.

Isso não é revisionismo. É análise de resultados orientada a outcomes.

“O XGH diz: se funciona, não mexa. O XGU diz: se funciona e o valuation subiu, não mexa — e escreva um case study sobre como você fez.”

Quer entender os pilares técnicos do XGU em profundidade? Veja Os Pilares.