# Como começar um projeto novo do zero em 2026

> Published 2026-10-12T22:58:27.071Z on https://www.crazystack.com.br/pt/p/como-comecar-um-projeto-novo-do-zero-em-2026/
> Source video: https://www.youtube.com/watch?v=PADhI0fZnTI

Para começar um projeto novo, escolha a stack pelo objetivo e faça o deploy do boilerplate ainda no primeiro dia. Só depois entram ORM com migrations, pipeline de testes e documentação para IA. Essa ordem evita o ciclo de horas debugando um deploy que só funciona na sua máquina.

## Como começar um projeto novo: a ordem que evita retrabalho

Para começar um projeto novo, defina a stack pelo objetivo, escreva a estrutura inicial e faça o deploy do boilerplate antes de qualquer funcionalidade. Augusto Galego, criador de conteúdo sobre algoritmos e system design, descreve essa sequência em um vídeo publicado em 19 de junho de 2026. A lógica é simples: problemas de infraestrutura aparecem cedo, quando o custo de corrigi-los ainda é baixo.

O erro mais comum é construir tudo localmente e só depois tentar publicar. Você sobe um banco na sua máquina, configura a infraestrutura toda e, ao levar para um provedor, o deploy não funciona. Aí vêm horas de depuração, já com o projeto cheio de código que você não quer jogar fora.

Inverter a ordem resolve isso. O projeto nasce em produção, mesmo que seja só um 'Hello World' com uma landing page vazia. Cada mudança que você faz na base de código é validada contra o ambiente real desde o primeiro commit.

Essa é a diferença entre um projeto que evolui e um que acumula remendos. A sequência abaixo reproduz o encadeamento descrito no vídeo e serve como roteiro para o seu primeiro dia de trabalho.

## Escolha da stack: aprender ou faturar?

A escolha da stack na largada depende de uma pergunta única: o projeto existe para aprender ou para gerar receita? Se o objetivo é aprendizado, faz sentido escolher Elixir, Go ou Rust — linguagens que você ainda não domina e quer explorar. Se o objetivo é dinheiro, a escolha tende a cair no que você já domina.

Nesse segundo caso, JavaScript costuma aparecer como a linguagem mais popular entre as opções disponíveis. Quem trabalha com Go inicia um projeto em Go. Quem trabalha com PHP, Ruby ou Python faz o mesmo. O foco deixa de ser a tecnologia nova e passa a ser o tempo até o produto rodar.

Dentro da linguagem, entra a decisão do framework. Para um desenvolvedor solo construindo um SaaS que precisa encontrar os primeiros usuários, frameworks com mais recursos prontos tendem a ser mais rápidos para sair do zero. É o caso do [Django](https://www.djangoproject.com/) no Python e do [Laravel](https://laravel.com/) no PHP, que já trazem painel de administração, camada de modelos e convenções estabelecidas.

A alternativa é compor a stack por conta própria, com um Node mais Express e uma pilha de plugins agregados. Isso dá mais controle, mas exige mais decisões antes da primeira linha de código de negócio. Para aprender, pode ser exatamente o que você quer. Para faturar, costuma custar tempo.

## Como alinhar framework e natureza do projeto

A natureza do projeto deve determinar o framework, não o contrário. Uma single page application pode se beneficiar de [Next.js](https://nextjs.org/), o framework React para produção mantido pela Vercel. Um backend com carga computacional pesada raramente combina com Python ou JavaScript puros, porque o custo de processamento aparece justamente onde essas linguagens são menos eficientes.

Conversar com uma IA para levantar possibilidades é útil nessa etapa, desde que você trate a resposta como insumo de discussão e não como decisão final. Use a ferramenta para enumerar alternativas e comparar trade-offs que você já conhece. A decisão continua sua, porque é você quem vai manter o código.

Se o seu projeto é um n8n self-hosted ou uma automação de workflows, a escolha é diferente da de um SaaS com banco relacional. O [n8n](https://n8n.io/) é uma ferramenta de automação de workflows com código aberto, que você pode hospedar em uma VPS própria. Já um SaaS sério vai precisar de banco de dados, migrations e controle de acesso desde o início.

Vale registrar uma ressalva prática: esses frameworks evoluem rápido e mudam de recomendação com frequência. Confirme a versão estável e os requisitos de ambiente na documentação oficial antes de fixar a decisão em um documento de projeto.

## O deploy imediato do boilerplate

O primeiro passo depois de escolher a stack é fazer o deploy do boilerplate, mesmo que ele não faça nada. A maioria dos frameworks entrega um projeto inicial com um 'Hello World' funcional. Esse projeto vai para produção antes de qualquer funcionalidade ser escrita.

O motivo é direto. Quando você publica cedo, cada problema de configuração aparece no momento em que surge, e não acumulado no fim. Se algo quebrar no ambiente de produção, você corrige com a base de código pequena e o contexto fresco na cabeça.

A automação do deploy é a fase seguinte. Com [GitHub Actions](https://github.com/features/actions), você configura um fluxo de integração e entrega contínua que roda a cada merge na branch principal. Assim, cada alteração chega ao servidor sem intervenção manual e sem script improvisado na máquina local.

A recomendação de infraestrutura no material original é uma VPS. No caso, a HostGator é patrocinadora do canal que produziu o vídeo — a menção tem esse caráter comercial, e o critério de escolha de qualquer provedor deve passar por latência, região dos servidores e custo em real, não pela recomendação em si. O que importa é que o deploy automático esteja no primeiro commit, não no trigésimo.

## ORM e migrations: banco versionado desde o dia um

A regra é usar uma ORM enxuta, com migrations, schema e type safety — e não uma que resolva tudo por você. ORM, ou mapeamento objeto-relacional, é a camada que traduz tabelas em estruturas de código. O valor real está na geração automática de arquivos de migration, no schema versionado e na checagem de tipos.

A preferência declarada é por bibliotecas pequenas, próximas do SQL. No ecossistema JavaScript, o [Drizzle ORM](https://orm.drizzle.team/) aparece como exemplo de ferramenta minimalista com tipagem forte. E há outras opções igualmente válidas — a escolha específica importa menos que os três recursos: migration, schema e tipos.

Projetos que não precisam de banco de dados existem. Uma landing page isolada provavelmente não vai ter um. Já um SaaS com usuários, planos e cobrança vai ter, e é aí que a migration no primeiro dia faz diferença.

O passo concreto é configurar o banco de desenvolvimento e fazer o deploy disparar as migrations automaticamente. No primeiro dia de projeto, o resultado é um 'Hello World' que não faz nada, uma tabela de usuários criada e o ambiente de produção já estável. Isso evita que a primeira migration vire um problema meses depois, quando a base já tem dados reais.

## Testes na pipeline antes da primeira feature

Testes entram antes da primeira funcionalidade, não depois dela. A pipeline que roda a suíte a cada merge garante que nenhuma alteração entre em produção sem passar pelas verificações. É uma etapa de configuração, não de código de negócio, e por isso cabe no começo do projeto.

A escolha da ferramenta importa menos que a existência da etapa. No ecossistema JavaScript, [Vitest](https://vitest.dev/) é uma opção comum para testes unitários, e [Cypress](https://www.cypress.io/) aparece com frequência nos testes ponta a ponta. O próprio autor do vídeo diz não se importar muito com a escolha, porque as ferramentas são parecidas em capacidade.

O ganho é de robustez. Um projeto sem testes automatizados depende de verificação manual a cada mudança, e essa verificação não escala conforme o número de funcionalidades cresce. Com a pipeline ativa desde o início, a regressão é detectada no pull request, não no ambiente do usuário.

Vale ser preciso sobre o escopo: cobertura de testes não garante ausência de bugs. Ela reduz a chance de regressões conhecidas e força você a descrever o comportamento esperado do sistema antes de implementá-lo.

## README e agents.md: documentar para você e para a IA

O último passo do setup é documentar, e essa etapa ganhou peso com o uso de assistentes de código. O README precisa registrar como instalar as dependências, como rodar o projeto localmente, quais são os comandos de teste, quais decisões de stack foram tomadas e quais são as convenções da base de código.

Há um segundo arquivo, geralmente chamado de agents.md, que orienta o assistente de IA que trabalha no repositório. Ele descreve como rodar os testes, se o projeto deve seguir TDD, quais são os padrões de tipagem, qual é a arquitetura, como o código se organiza em serviços e qual é o objetivo explícito do projeto.

Esse contexto reduz o retrabalho. Sem ele, cada sessão com a IA recomeça do zero e tende a produzir código fora do padrão que você estabeleceu. Com o arquivo no repositório, as decisões ficam registradas e a ferramenta as segue.

Documentação técnica e documentação para IA se sobrepõem em boa parte. O README serve a quem chega novo no projeto, incluindo você mesmo daqui a seis meses. O agents.md serve ao assistente. Manter os dois atualizados conforme o projeto cresce é o que sustenta a consistência.

## Ferramentas e convenções no ecossistema brasileiro

Comunidades brasileiras publicam trilhas próprias para quem está começando um projeto novo, e algumas delas concentram decisões de stack em um só lugar. É o caso do [Crazystack](https://crazystack.com.br), que reúne uma stack TypeScript com convenções definidas para projetos do zero.

Nesse contexto aparecem referências como o Crazystack Typescript, que organiza escolhas de framework, ORM e ferramentas em uma base única, e conteúdos como o Bootcamp do Dev Doido, associado a Gustavo Dev Doido. Esses materiais funcionam como ponto de partida para quem prefere adotar uma convenção pronta em vez de decidir cada peça isoladamente.

A ressalva é a mesma de qualquer stack pré-montada: ela reflete as escolhas de quem a mantém, em um momento específico. Antes de adotá-la, verifique se as versões das ferramentas citadas ainda são as atuais e se as decisões de arquitetura fazem sentido para o seu tipo de projeto.

A sequência descrita neste artigo — stack, estrutura, deploy, banco, testes, documentação — funciona com qualquer stack. A convenção que você escolhe muda as ferramentas, não a ordem das decisões.

## FAQ sobre começar um projeto novo

- **Qual é o primeiro passo para começar um projeto novo?**

O primeiro passo é escolher a stack com base no objetivo do projeto: aprender uma tecnologia nova ou gerar receita com algo que você já domina. Em seguida, escreva a estrutura inicial do MVP em um documento antes de codar. O deploy do boilerplate vem logo depois, ainda no primeiro dia.

- **Por que fazer deploy antes de escrever funcionalidades?**

Porque problemas de infraestrutura aparecem cedo e custam pouco para corrigir. Quando você publica um boilerplate vazio, cada ajuste de ambiente é validado imediatamente. Se deixar o deploy para o fim, a depuração acontece com a base de código cheia e o contexto perdido.

- **Preciso usar ORM ou posso escrever SQL direto?**

Você pode escrever SQL direto, mas uma ORM enxuta resolve três coisas de uma vez: geração automática de migrations, schema versionado e type safety na base de código. A preferência declarada é por bibliotecas pequenas e próximas do SQL, como o Drizzle no ecossistema JavaScript.

- **Quais testes configurar no início do projeto?**

Testes unitários e testes ponta a ponta rodando na pipeline a cada merge. No ecossistema JavaScript, Vitest e Cypress são opções comuns. A ferramenta importa menos que a existência da etapa automatizada antes da primeira funcionalidade.

- **O que deve estar no README de um projeto novo?**

Como instalar as dependências, como rodar localmente, quais são os comandos de teste, quais decisões de stack foram tomadas e quais são as convenções da base de código. Esse conjunto responde às perguntas que você mesmo vai fazer daqui a alguns meses.

- **Para que serve um arquivo agents.md?**

Ele orienta assistentes de código que trabalham no repositório. Descreve como rodar os testes, se o projeto segue TDD, quais são os padrões de tipagem, qual é a arquitetura e qual é o objetivo explícito do projeto. Sem esse contexto, cada sessão com a IA recomeça do zero.

- **Quando usar um framework com mais recursos prontos?**

Quando você é desenvolvedor solo e precisa sair do zero rápido até os primeiros usuários. Django, Laravel e frameworks semelhantes trazem painel de administração e camada de modelos prontos. A alternativa de compor a stack manualmente dá mais controle, mas consome mais tempo de decisão.

- **Frameworks com mais recursos prontos são sempre melhores?**

Não. Em projetos com carga computacional pesada no backend, a escolha muda, porque o custo de processamento aparece onde essas linguagens são menos eficientes. A regra é alinhar o framework à natureza do projeto, não seguir uma preferência genérica.

- **Como documentar o projeto para trabalhar com IA?**

Mantenha o README e o agents.md atualizados conforme a base cresce. Registre comandos, convenções, arquitetura e objetivo do projeto. Esse material serve tanto para quem entra no repositório quanto para o assistente que gera código dentro dele.

- **Vale a pena adotar uma stack brasileira pronta?**

Vale quando você prefere uma convenção definida em vez de decidir cada peça isoladamente. O [Crazystack](https://crazystack.com.br) é um exemplo disso no ecossistema TypeScript. Verifique antes se as versões citadas ainda são as atuais e se a arquitetura combina com o seu projeto.

## Do vídeo ao artigo: seu conhecimento em texto

A ordem que este artigo descreve — stack, estrutura, deploy, banco, testes, documentação — nasceu de um vídeo, não de um documento escrito. O mesmo vale para a maior parte do conhecimento técnico que circula hoje: fica registrado em vídeo, com a explicação oral e os exemplos ao vivo, mas sem um texto que alguém possa consultar depois.

Se você tem explicações, entrevistas, opiniões ou lições gravadas em vídeo, elas podem virar artigo. No [Skala Blog](https://skalablog.com), você cola a URL do vídeo, o conteúdo é transcrito e o artigo é gerado a partir dele. O passo a passo que você já explicou uma vez deixa de depender de quem assiste até o fim.

[Source video](https://www.youtube.com/watch?v=PADhI0fZnTI)