Quando comecei a trabalhar como programador, ainda havia muita coisa para aprender. Então era natural continuar estudando no tempo livre, fazendo cursos, lendo documentação e tentando pegar tarefas cada vez mais difíceis no trabalho.

Durante um bom tempo isso funcionou.

Só que chegou um momento em que comecei a sentir que estava andando em círculos. Eu já dominava boa parte das responsabilidades do dia a dia e, mesmo procurando tarefas que me obrigassem a aprender algo novo, aquela sensação de evolução acelerada do começo já não existia mais.

Foi aí que comecei a pensar que precisava construir alguma coisa fora do trabalho.

O problema era descobrir o quê.

E talvez esse seja um dos maiores bloqueios de quem quer começar um side project.

Você abre o Google, Reddit, YouTube ou qualquer outra coisa e procura:

ideias de projetos para programadores ideias de SaaS ideias de micro SaaS projetos para portfólio side project ideas

Aparecem centenas de sugestões.

Mesmo assim, nenhuma parece realmente interessante.

Comigo foi assim também.

Eu estava procurando a ideia no lugar errado

Minha primeira tentativa foi pensar nas coisas de que eu gostava.

Isso fazia sentido para mim porque já tinha funcionado antes.

Quando era mais novo, criei um site voltado para anime, com sistema de downloads e comunidade. O projeto acabou crescendo bastante e chegou a receber milhares de visitantes únicos por dia.

Naquela época eu passava horas mexendo no site simplesmente porque gostava daquilo.

Então pensei que bastava encontrar novamente algum assunto de que eu gostasse e construir algo em torno dele.

Só que nada me empolgava da mesma forma.

Foi quando comecei a mudar a pergunta.

Em vez de:

O que eu gostaria de desenvolver?

comecei a pensar:

Que problemas as pessoas ao meu redor têm que eu poderia tentar resolver com software?

Parece uma mudança pequena, mas fez uma diferença enorme.

Pergunte para as pessoas como elas trabalham

Comecei a prestar mais atenção quando amigos e conhecidos falavam sobre seus trabalhos.

Não precisava ser nenhuma conversa formal sobre tecnologia.

Às vezes alguém comentava que fazia determinada coisa em uma planilha, anotava pedidos em papel, precisava responder as mesmas mensagens todos os dias ou tinha algum processo extremamente manual.

E comecei a reparar nesses detalhes.

Planilhas gigantes.

Papel.

WhatsApp.

Copiar e colar informação de um lugar para outro.

Conferências manuais.

Contas feitas na calculadora.

Informações espalhadas.

Tarefas repetitivas.

Essas coisas não parecem ideias incríveis de startup.

Na verdade, muitas vezes são problemas bem chatos.

Mas alguém precisa lidar com eles todos os dias.

E é justamente aí que pode existir uma boa ideia de side project.

Meu primeiro teste foi uma lanchonete

Um amigo meu tinha uma lanchonete e praticamente toda a operação era manual.

O delivery era atendido pelo WhatsApp por um funcionário, os pedidos eram anotados, não existia muita automação e havia pouco controle sobre várias partes da operação.

Obviamente já existiam — e continuam existindo — milhares de sistemas para lanchonetes.

Esse detalhe é importante.

Minha primeira reação poderia ter sido:

“Já existe software para isso. Não faz sentido criar outro.”

Mas resolvi olhar para o problema de outra forma.

Eu não precisava criar o melhor sistema de lanchonetes do Brasil.

Precisava entender o problema daquela lanchonete.

Comecei a conversar com ele para descobrir quais eram as dificuldades, o que mais atrapalhava a operação, quais coisas eram prioridade e como ele imaginava uma solução.

Depois comecei a construir.

No início, nem existia sistema de verdade.

Fiz apenas as telas utilizando dados mockados e ia mostrando para ele conforme avançava.

Em cerca de um mês boa parte das telas estava pronta.

Quando mostrei, ele ficou animado e achou que o sistema praticamente já estava funcionando.

Precisei explicar:

Aquilo era a carroceria do carro. Estava bonita, mas ainda não tinha motor.

As telas existiam, mas por trás delas ainda faltava praticamente tudo.

Banco de dados, autenticação, pedidos, regras de negócio, integrações, pagamentos, infraestrutura e dezenas de coisas que eu ainda nem sabia que seriam necessárias.

O sistema só começou a funcionar de verdade em produção cerca de um ano e meio depois.

Pode parecer muito tempo para um side project.

Só que hoje existem pessoas reais usando aquilo diariamente.

E, olhando para trás, percebo que o maior retorno daquele projeto não veio quando ele ficou pronto.

Veio durante o processo de tentar fazê-lo funcionar.

Um usuário real muda completamente o projeto

Existe uma diferença enorme entre desenvolver algo para demonstrar conhecimento e desenvolver algo que alguém realmente precisa usar.

Em um projeto de estudo, se alguma coisa quebrar, você pode fechar o notebook e resolver depois.

Quando alguém usa seu sistema para trabalhar, a conversa muda.

Você começa a lidar com coisas que dificilmente aparecem em um tutorial.

O usuário utiliza uma funcionalidade de uma forma que você nunca imaginou.

Uma regra de negócio que parecia simples ganha cinco exceções.

Algo que parecia óbvio na interface não é óbvio para quem está utilizando.

Uma alteração pequena começa a afetar outras partes do sistema.

Você precisa atualizar a aplicação sem quebrar o que já está funcionando.

Começa a pensar em dados, backups, logs, segurança, infraestrutura e disponibilidade.

É nesse momento que o projeto deixa de ser apenas código.

Ele passa a ser um sistema.

E isso ensina muito.

“Mas isso já existe”

Depois dessa experiência, uma coisa mudou bastante na forma como penso sobre projetos.

Eu parei de me preocupar tanto em encontrar uma ideia completamente original.

Se alguém me conta um problema e eu descubro que existem dez empresas vendendo software para resolvê-lo, isso não significa necessariamente que devo desistir.

Na verdade, pode significar justamente o contrário.

Se existem empresas cobrando por aquilo, provavelmente existe um problema real sendo resolvido.

A pergunta passa a ser:

Por que essa pessoa ainda tem esse problema se já existem soluções no mercado?

Talvez as soluções sejam caras.

Talvez sejam complexas demais.

Talvez não atendam uma particularidade daquele negócio.

Talvez sejam ruins de usar.

Ou talvez aquela pessoa simplesmente nunca tenha encontrado uma solução que faça sentido para ela.

Você não precisa inventar uma categoria nova de software para construir alguma coisa útil.

Às vezes basta resolver melhor um problema que já existe para um grupo pequeno de pessoas.

O próximo projeto veio de uma planilha

Depois que o primeiro sistema começou a funcionar, outras pessoas começaram a aparecer com ideias.

Moro em um lugar pequeno, com aproximadamente mil habitantes, então as coisas se espalham rápido.

E surgiram pedidos de todo tipo.

Alguns bem interessantes.

Outros bastante... criativos.

Mas uma dessas conversas chamou minha atenção.

Uma pessoa trabalhava vendendo pacotes de turismo e excursões.

Grande parte da operação era feita através de planilhas, pagamentos manuais e processos que dependiam de alguém conferir informações.

Minha reação inicial foi:

“Isso parece simples. Dá para fazer um sistema de reservas, integrar um gateway de pagamento e automatizar boa parte disso.”

Na teoria realmente parecia simples.

O cliente cadastraria as viagens, os passageiros fariam as reservas, o pagamento seria processado automaticamente e o responsável apenas administraria tudo.

Na prática, apareceram várias regras de negócio que eu sequer tinha considerado no início.

Mesmo assim, em cerca de dois meses o sistema já estava funcionando em produção.

E então começaram os problemas que só aparecem quando existe uso real.

Como os pacotes vendidos tinham valores relativamente altos, surgiram dificuldades relacionadas a antifraude nos pagamentos.

Em outro momento, foi feita uma campanha de marketing para o lançamento de uma excursão.

Muita gente acessou o sistema ao mesmo tempo.

O sistema não aguentou.

E travou.

Não existe curso que consiga reproduzir exatamente a sensação de descobrir que sua aplicação está fora do ar enquanto pessoas reais estão tentando comprar alguma coisa.

Também não existe aprendizado melhor.

A partir daquele problema surgem novas perguntas.

Por que caiu?

Onde estava o gargalo?

Quantas requisições estávamos recebendo?

O banco estava preparado?

A infraestrutura estava dimensionada corretamente?

Como evitar que isso aconteça novamente?

Como saber que alguma coisa está dando errado antes do usuário reclamar?

De repente, assuntos que poderiam parecer apenas tópicos de estudo passam a ter um motivo concreto para serem aprendidos.

Um beta tester pode valer mais que uma ideia brilhante

Por isso, hoje eu daria muito mais valor a uma ideia comum com uma pessoa disposta a utilizá-la do que a uma ideia genial sem nenhum usuário.

Ter alguém próximo disposto a testar sua aplicação é extremamente valioso.

Você consegue perguntar:

Se eu fizer algo para resolver isso, você usaria?

A pessoa não precisa investir dinheiro.

Não precisa assinar contrato.

Não precisa acreditar que você vai construir a próxima grande startup.

Ela só precisa estar disposta a experimentar.

Isso já muda completamente a qualidade do feedback que você recebe.

Porque existe uma diferença enorme entre alguém dizer:

“Achei legal.”

e alguém dizer:

“Tentei usar isso hoje e não consegui fazer meu trabalho porque essa parte não funciona.”

O segundo feedback pode doer um pouco mais.

Mas também vale muito mais.

No começo, seu SaaS não precisa dar dinheiro

Também demorei um pouco para perceber outra coisa.

Nem todo side project precisa nascer pensando em faturamento.

Existe atualmente uma obsessão grande com transformar qualquer projeto em micro SaaS, conseguir os primeiros clientes, acompanhar MRR e tentar chegar rapidamente em algum valor de receita recorrente.

Não há nada errado em querer ganhar dinheiro com seu software.

É exatamente isso que permite que um produto continue existindo e crescendo.

Mas essa não precisa ser a primeira métrica.

Principalmente no começo.

Se você colocou um software em produção e existe uma pessoa utilizando aquilo no dia a dia, já existe um aprendizado enorme acontecendo.

Você vai lidar com deploy.

Dados reais.

Bugs reais.

Usuários reais.

Requisitos que mudam.

Problemas de infraestrutura.

Pagamentos.

Integrações.

Suporte.

Segurança.

Backup.

Manutenção.

São problemas muito diferentes daqueles encontrados quando seguimos um tutorial do começo ao fim.

Por isso, mesmo que o seu primeiro usuário seja um amigo utilizando gratuitamente, o projeto pode estar entregando um retorno enorme para você.

Só que o retorno naquele momento está vindo na forma de experiência.

Isso não significa trabalhar gratuitamente para sempre.

Se o projeto crescer, tiver custos e começar a exigir seu tempo constantemente, obviamente ele precisará encontrar uma forma de se sustentar.

A questão é apenas não considerar um projeto fracassado porque ele ainda não está pagando suas contas.

Antes de tentar fazer seu side project gerar receita, talvez a primeira meta devesse ser muito mais simples:

Faça alguma coisa que uma pessoa realmente consiga usar para resolver um problema.

Construa para uma pessoa antes de pensar em mil

Outro erro fácil de cometer é começar um projeto já imaginando uma escala que ainda não existe.

Qual arquitetura vai suportar cem mil usuários?

Será que deveria usar microserviços?

Como vou criar vários planos?

Preciso de Kubernetes?

Como vou internacionalizar?

Que estratégia de crescimento vou usar?

Enquanto isso, ainda não existe uma única pessoa utilizando o sistema.

Hoje prefiro começar de outra forma.

Primeiro:

Consigo resolver o problema desta pessoa?

Depois:

Existem outras pessoas com o mesmo problema?

E só então:

Como transformo isso em um produto?

Quando você começa com uma pessoa real, recebe restrições reais.

Ela usa um celular diferente do seu.

Ela chama determinado processo por outro nome.

Ela não entende aquele botão que para você parecia completamente óbvio.

Ela faz alguma coisa em uma ordem que você nunca imaginaria.

Ela pede uma funcionalidade que revela que você entendeu errado parte do problema.

Tudo isso ajuda a construir um software melhor.

O processo que acabou funcionando para mim

Eu não comecei seguindo nenhum método.

Ele simplesmente apareceu conforme fui construindo meus projetos.

Hoje consigo resumir mais ou menos assim:

Pessoa
  ↓
Problema
  ↓
Conversa
  ↓
Solução pequena
  ↓
Beta tester
  ↓
Uso real
  ↓
Aprendizado
  ↓
Produto
  ↓
Receita

A receita está no final não porque ela seja pouco importante.

Mas porque existe bastante coisa para descobrir antes de chegar nela.

Primeiro é preciso descobrir se o problema realmente existe.

Depois se alguém aceita sua solução.

Depois se essa solução funciona no mundo real.

Só depois começa a fazer sentido pensar seriamente em transformar aquilo em um negócio.

Talvez sua próxima ideia esteja mais perto do que parece

Hoje eu praticamente parei de procurar listas de ideias de side projects.

Prefiro conversar com as pessoas.

Quando alguém começa a explicar como funciona seu trabalho, principalmente quando reclama de alguma parte dele, presto atenção.

Nem todo problema precisa virar software.

Nem toda ideia precisa virar SaaS.

E nem todo projeto precisa virar uma empresa.

Mas colocar alguma coisa que você construiu nas mãos de uma pessoa real pode ensinar muito mais do que construir dezenas de projetos que terminam esquecidos em um repositório no GitHub.

Então, da próxima vez que você estiver sem ideia do que desenvolver, talvez não precise procurar uma lista na internet.

Converse com alguém próximo e faça uma pergunta simples:

Qual é a parte mais chata do seu trabalho?

Talvez seu próximo side project esteja na resposta.