Ideias de projetos de programação para iniciantes: vão ao ar

Estas ideias de projetos de programação para iniciantes são pequenas, ficam prontas em uma semana e terminam com uma URL no ar. Um painel de clima sobre uma API pública, uma API REST própria, um serviço de favoritos com health check e um projeto que você quebra de propósito e depois conserta. Nada de clones de tutorial. Escolha uma ideia, publique em um host de verdade e mostre para uma pessoa.

São 14h40 de uma terça-feira e um aluno posta num servidor do Discord: "Meu app de tarefas funciona no meu notebook. Como eu coloco isso no ar?" Ninguém responde por uma hora. Essa lacuna, entre "funciona localmente" e "funciona para outra pessoa", é onde a maioria dos projetos de iniciantes morre. Esta lista foi montada para fechar essa lacuna.

Por que um projeto de iniciante precisa de uma URL no ar?

Um repositório no seu notebook prova que você sabe seguir instruções. Um serviço publicado prova que você consegue lidar com configuração, segredos, porta, etapa de build e uma falha, tudo ao mesmo tempo. Esse é o trabalho de verdade.

A Sigma School defende o mesmo argumento: o primeiro projeto deve terminar com uma URL no ar, e um link publicado, mostrado a uma pessoa real, vale mais do que três repositórios inacabados. Concordamos, com uma ressalva. A URL é o piso, não a linha de chegada. A linha de chegada é um projeto que você consegue explicar quando algo quebra.

Este é o filtro que usamos para cada ideia da lista. Dá para construir em menos de 10 horas? Ele chama ou expõe uma API? Dá para publicar de graça? Tem pelo menos uma forma de falhar que você consegue observar? Se a resposta for não para qualquer uma dessas perguntas, é um exercício de tutorial, não um projeto.

Qual primeiro projeto ensina mais por hora?

O projeto um é um painel de clima ou de cotações que consome uma API pública. Parece fácil demais. Não é, porque obriga você a passar pelas quatro coisas que qualquer serviço real faz: enviar uma requisição, esperar, interpretar a resposta e tratar o caso em que a resposta está errada.

O roteiro de ideias de API da Strapi cita os suspeitos de sempre: clima, busca de filmes, conversão de moedas, uma Pokédex, um explorador de países. O detalhe mais útil é o alerta de que o plano gratuito da NewsAPI é restrito a ambientes de desenvolvimento, então um agregador de notícias construído sobre ela não serve como demo ao vivo. Leia os termos da API antes de escolher o projeto, não depois de ter construído a interface.

Nossa escolha para uma primeira versão é um conversor de moedas ou um explorador de países. Os dois têm limites generosos ou não publicados, não exigem rotação de chaves e têm formatos de resposta estáveis. O clima também funciona, mas você vai gastar uma tarde com chaves de API e CORS antes de escrever uma linha interessante.

O que construir na primeira versão:

• Uma página, um campo de entrada, uma chamada de API, um resultado renderizado

• Timeout de 3 segundos na chamada de saída, para que uma origem lenta não trave a sua página

• Um estado de erro visível quando a chamada falha, e não uma tela em branco

• Resposta em cache por 60 segundos, para que atualizar a página não sobrecarregue o plano gratuito

O último item é a lição. Cache e timeout são as primeiras decisões de confiabilidade que você vai tomar, e vai tomá-las em um projeto sem usuários e sem consequências.

O que construir quando você estiver pronto para ser dono da API?

O projeto dois inverte a direção. Em vez de consumir a API de outra pessoa, você expõe a sua. Um serviço de favoritos tem o tamanho certo: criar, listar, excluir e marcar com tags. Quatro endpoints, uma tabela, uma tarde.

Escreva em TypeScript ou Go. As duas linguagens obrigam você a ser explícito sobre tipos na fronteira, exatamente onde moram os bugs de iniciante. Adicione um endpoint que a maioria dos tutoriais ignora, um health check:

// GET /healthz: retorna 200 somente se o banco responder
app.get("/healthz", async (_req, res) => {
  try {
    await db.query("select 1");
    res.status(200).json({ status: "ok" });
  } catch {
    res.status(503).json({ status: "degraded" });
  }
});

São dez linhas, e você acabou de aprender a diferença entre um processo que está rodando e um serviço que está funcionando. Toda plataforma de hospedagem pode consultar essa rota e reiniciar o serviço quando ela falhar. Ninguém ensina isso na primeira semana. Deveriam ensinar.

Depois, publique. Qualquer host com plano gratuito que faça build a partir de um repositório Git serve. Coloque a URL do banco em uma variável de ambiente, não no repositório. Commite um .env.example com valores falsos. Se você subir um segredo real para um repositório público uma única vez, nunca mais vai fazer isso, e é melhor aprender com um banco descartável.

Deixe de lado a divisão em microsserviços, a fila de mensagens e o manifesto do Kubernetes. Você tem um serviço. Trate-o como um serviço.

Como adicionar um recurso de IA sem construir um brinquedo?

Adicione um, e faça pequeno. A pesquisa da Stack Overflow de 2025 encontrou que 84% dos respondentes usam ou planejam usar ferramentas de IA no processo de desenvolvimento, e 51% dos desenvolvedores profissionais as usam diariamente. Hoje, as empresas esperam que você tenha chamado uma API de LLM pelo menos uma vez. A questão é se você fez isso com responsabilidade.

Um projeto de IA responsável para iniciantes tem três propriedades. Ele define um timeout rígido na chamada ao modelo. Tem um caminho de fallback que funciona quando o modelo está fora do ar ou lento. E registra a latência de cada chamada, para que você consiga enxergar o p95. Um sumarizador para o seu serviço de favoritos é uma boa escolha: você cola uma URL, recebe um resumo de duas frases e, se a chamada falhar, usa o título da página.

Se você usa um assistente para escrever o código, trate o resultado como um pull request de um desconhecido. Leia, rode e quebre. Assistentes como o GitHub Copilot e o agente da Replit são úteis para montar a estrutura, e são exatamente tão confiáveis quanto a revisão que você faz. A mesma pesquisa mostra que a confiança na precisão da IA é baixa: apenas 29% dos respondentes dizem confiar nela. Esse número é um bom ponto de partida para os seus próprios hábitos de revisão.

O que acontece quando você quebra o projeto de propósito?

Esta é a ideia que ninguém coloca em lista, e é a que daríamos a todo iniciante. Pegue o seu serviço de favoritos publicado e provoque três falhas. Derrube a conexão com o banco. Faça a chamada de saída à API devolver um 500. Envie um corpo de requisição dez vezes maior do que o aceitável.

Cada falha ensina uma pergunta: o que o usuário vê, e como você descobre? A resposta para a segunda metade é observabilidade, e você pode começar com quase nada. Registre uma linha JSON por requisição, com o código de status e a duração em milissegundos. Só isso já permite responder "quantas requisições falharam na última hora" com um filtro de uma linha.

Quando você tiver alguns dias de logs, transforme-os em gráfico. O Grafana tem um plano gratuito mais do que suficiente para um serviço de hobby, e um único painel com p95 de latência e taxa de erro ensina mais do que um mês de leitura sobre SLOs. Defina uma meta, por exemplo 99% das requisições abaixo de 500 ms, e verifique se ela foi cumprida na semana passada. Isso é um SLO. Não é complicado, só é raramente praticado por quem nunca foi acordado por um alerta.

Iniciantes podem usar feature flags?

Podem, e é o hábito profissional mais barato que você pode adquirir. Uma feature flag é um if cujo valor vem da configuração, e não do código. Coloque uma em volta do resumo com IA. Publique com ela desligada. Ligue para você. Depois ligue para todos, e desligue de novo quando o provedor do modelo tiver uma queda.

Você não precisa de uma plataforma para isso. Uma variável de ambiente já é uma flag. Um arquivo JSON é uma flag com raio de impacto maior. Quando você crescer além disso, existem opções gerenciadas, como LaunchDarkly e Statsig, e você vai entender por que precisa de uma depois de ter batido nos limites da versão caseira.

O hábito importa mais do que a ferramenta. Separar "publicado" de "liberado" transforma uma mudança ruim em uma troca de configuração, e não em um revert à meia-noite. Muitas equipes de produção ainda erram nisso. Você pode acertar com um projeto de 200 linhas.

Um plano de sete dias que você consegue concluir

Esta é a sequência que daríamos a um novo aluno, com um ponto de parada em cada dia.

• Dia 1: construa o painel de moedas ou de países. Só local. Uma chamada, uma renderização.

• Dia 2: adicione o timeout, o estado de erro e o cache de 60 segundos. Publique.

• Dia 3: comece a API de favoritos. Quatro endpoints, uma tabela, testes do caminho feliz.

• Dia 4: adicione o health check, mova os segredos para variáveis de ambiente e publique.

• Dia 5: adicione o resumo com IA atrás de uma flag, com timeout e fallback.

• Dia 6: adicione logs estruturados de requisição. Quebre o serviço de três formas e anote o que viu.

• Dia 7: escreva um README com um parágrafo por falha e o que você mudou. Envie a URL para uma pessoa.

Repare no que falta: um framework novo a cada dia. Escolha uma stack e fique nela. Profundidade em uma linguagem vale mais do que uma amostra de cinco, e os hábitos acima se transferem para qualquer stack.

O que deixaríamos de fora, e por quê?

Começando pelo app de tarefas. Ele aparece em toda lista de ideias de projeto para iniciantes, e todo recrutador já viu centenas deles. Não é errado, só é indiferenciado. A parte de CRUD ensina menos do que o serviço de favoritos, e ensina pior. Se você mesmo assim for construir um, mude a restrição: faça com vários usuários e autenticação real, funcione offline e sincronize depois, ou aguente duas abas do navegador editando o mesmo item. O aprendizado está nessas restrições, não na lista em si.

A mesma regra vale para calculadoras, geradores de números aleatórios e relógios digitais. Servem para o primeiro fim de semana com uma linguagem nova. Não são material de portfólio e não ensinam nada sobre colocar software no ar.

Deixe de lado tudo que não pode ser publicado. Um script Python local que renomeia arquivos é um utilitário razoável e uma péssima entrada de portfólio. Deixe de lado projetos que precisam de chaves de API pagas para a demo funcionar. Deixe de lado uma "rede social completa", porque você vai gastar seis semanas em telas de login e não vai aprender nada sobre rodar software.

Deixe de lado também as continuações de tutorial. Se você fez o mesmo curso duas vezes, o terceiro projeto deve ser aquele em que ninguém deu a resposta. Esse desconforto é o ponto.

O que vale a pena: qualquer coisa que tenha uma URL, um endpoint, um modo de falha e um README que admita o que você errou. Um projeto assim diz mais sobre você do que um clone bem polido.

Então fica a pergunta para levar com você. Quando o seu primeiro projeto falhar na frente de um desconhecido, você vai saber disso antes que ele saiba?