Como começar um projeto novo do zero em 2026

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 no Python e do Laravel 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, 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 é 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, 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 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 é uma opção comum para testes unitários, e Cypress 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, 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 é 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, 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