Em 2012, Eric Barone tinha acabado de se formar em ciência da computação pela Universidade de Washington, em Tacoma, e não conseguia emprego na área. Resolveu fazer um joguinho de fazenda para treinar programação e colocar no portfólio. Ele desenhou cada personagem, compôs cada música, escreveu cada linha de código e cada diálogo, sozinho, por uns quatro anos. O joguinho virou Stardew Valley, e até o fim de 2024 tinha vendido mais de 41 milhões de cópias. É a história que todo indie dev conta para si mesmo antes de dormir.
Naquele mesmo ano de 2012 saiu um documentário que mostra o outro lado da moeda. Indie Game: The Movie acompanha o Edmund McMillen e o Tommy Refenes nas semanas finais de Super Meat Boy, o Phil Fish anos atolado no desenvolvimento de Fez e o Jonathan Blow, de Braid, falando do que vem depois do sucesso. Tem pouco glamour ali. Tem gente exausta, com medo de o lançamento dar errado, olhando contador de vendas às duas da manhã e apostando a própria saúde num projeto que pode não dar em nada. Se você quer entender como é ser desenvolvedor indie sem ler nenhum artigo, assiste esse filme.
Eu sou o desenvolvedor da Lobbix+, uma rede social de filmes e séries que eu construí na raça. Já contei aqui no blog como vendi meu carro para criar uma rede social de séries. Desta vez quero falar do dia a dia de quem constrói assim, sem time grande e sem investidor bancando a conta: o que é bom, o que é pesado e por que eu continuo escolhendo esse caminho.
O que é ser indie dev
Indie dev, ou desenvolvedor independente, é quem cria e mantém um produto de software por conta própria, sozinho ou com uma equipe minúscula, sem uma empresa grande por trás. O termo nasceu nos games, mas hoje cobre também quem faz app, SaaS e rede social. Lá fora o pessoal fala em indie hacker e solo founder. No Brasil a gente fala mesmo é "empreender sozinho". Na prática, você é o programador, o designer, o suporte, o marketing, o financeiro e o cara que responde a avaliação de uma estrela na loja de apps às onze da noite de domingo.
Um cérebro só decide muito rápido
De tudo, essa é a parte que eu mais gosto. Quando uma decisão passa por um cérebro só, ela sai na hora. Não tem comitê, não tem reunião para marcar a reunião, não tem slide para convencer diretor. Eu acordo com uma ideia, decido se ela faz sentido e começo a construir antes do almoço. Isso desbloqueia uma habilidade que empresa grande nenhuma tem: entregar muito rápido.
Quando o TV Time anunciou que ia fechar, em julho de 2026, eu não precisei pedir permissão a ninguém para ir atrás dos órfãos do app. Tive a ideia de apresentar a Lobbix+ nos posts de quem estava reclamando do fechamento e fui. Naquela semana chegaram cerca de 1.300 usuários novos. Num time de vinte pessoas, a mesma ideia talvez tivesse virado item de pauta da semana seguinte, e a janela já teria fechado.
O holandês Pieter Levels, que criou o Nomad List e mais um monte de produtos sozinho, transformou essa velocidade em método. Em 2014 ele se desafiou a lançar 12 startups em 12 meses, e no livro MAKE ele defende construir pequeno, lançar rápido e ver se alguém paga. O Jason Fried e o David Heinemeier Hansson, do Basecamp, vão na mesma linha em Rework, que saiu no Brasil como Reinvente sua empresa. Um dos capítulos tem um título que eu adoro: Planejar é adivinhar.
Sem Two Factor Auth mental
A velocidade tem um preço. No celular, você tem a autenticação em dois fatores: antes de fazer algo sério, um segundo dispositivo confirma que é você mesmo. Num time, quem faz esse papel é o sócio, o tech lead, o colega que revisa o seu código e pergunta "tem certeza?". O indie dev não tem isso. Não existe um Two Factor Auth mental. A ideia que parecia genial à meia-noite vai direto para produção, sem ninguém para segurar o seu braço.
Então, sim, algumas coisas desandam. Uma funcionalidade sai antes da hora, uma escolha técnica cobra juros meses depois, um texto vai ao ar com um erro bobo. Eu aceito isso como parte do processo. Um texto no TabNews resume bem: um bug em produção para um time de um homem só é um pesadelo multiplicado por dez. É verdade. E também é verdade que o mesmo homem só conserta esse bug em vinte minutos, sem abrir chamado.
Move fast and break things
Nos primeiros anos do Facebook, o Mark Zuckerberg tinha um lema pendurado na parede: Move fast and break things. Mova-se rápido e quebre coisas. O espírito daquela fase aparece bem em A Rede Social, do David Fincher, com o Jesse Eisenberg programando madrugada adentro num quarto de alojamento de Harvard, enquanto os amigos se espremem em volta da tela.
Esse lema é a minha religião. Para quem está começando, ele resume tudo: lançar, aprender com o que quebrou, consertar, lançar de novo. Ficar parado polindo uma tela que ninguém vai ver custa mais caro que errar em público.
Tem um detalhe nessa história que eu acho ótimo. Em abril de 2014, na conferência F8, o próprio Zuckerberg trocou o lema por Move fast with stable infra, "mova-se rápido com infraestrutura estável". O motivo que ele deu foi bem prático: com o Facebook gigante, consertar os bugs estava deixando todo mundo mais lento. Ou seja, quebrar coisas é uma ferramenta da fase pequena. Quando a casa cresce, você ganha o seu segundo fator, seja um time, um processo ou uma infraestrutura que aguenta o tranco. Até lá, eu sigo rápido.
O preço que ninguém posta no LinkedIn
A outra metade de ser indie dev é a solidão. O japonês Takuya Matsuyama, que vive há anos de um app de anotações que ele mesmo criou, o Inkdrop, escreveu um texto muito honesto sobre isso. Ele diz que, por trás da liberdade e da independência, existe uma solidão silenciosa e o medo constante de que ninguém vai te segurar se você cair. Conta também que passou a se sentir valioso só quando os usuários gostavam do que ele construía, e que isso o levou ao burnout.
Uma reportagem da Game Developer ouviu desenvolvedores independentes e encontrou a mesma coisa: culpa na hora de descansar, porque se você parar ninguém termina o projeto por você. A liberdade de ser o próprio chefe e escolher o próprio horário vira uma camisa de força. Eu conheço bem essa sensação. Nos dois anos de Lobbix+, eu tive vários burnouts, e teve fase de uma, duas semanas em que meu cérebro simplesmente não funcionava e eu não conseguia tocar no projeto.
Tem ainda o silêncio. Quase todo indie dev já lançou alguma coisa e ouviu grilo. No Indie Hackers, sobra relato de gente que publicou o produto no Product Hunt, no Hacker News e no LinkedIn e viu meia dúzia de cadastros e mais nada. Projeto indie raramente morre de forma dramática. Ele morre quieto, e muita gente desiste justamente nessa fase, que às vezes é só o tempo entre lançar e as pessoas certas acharem você. A minha virada veio com o fim do TV Time. Antes dela, a Lobbix+ ainda não era nem minimamente popular.
Por que eu continuo
Porque a outra ponta compensa. Ver alguém que você nunca viu postando todo dia numa coisa que você construiu do zero, criando teoria sobre série e discutindo episódio com gente do país inteiro, é uma sensação difícil de explicar. O mesmo texto do TabNews tem uma frase que eu assinaria embaixo: fui eu quem construiu isso.
Se você é indie dev, ou está pensando em largar tudo para construir o seu projeto, três conselhos de quem está no meio do caminho. Guarde dinheiro antes, porque projeto ambicioso demora e cansaço mata foco. Decida rápido e aceite que vai quebrar coisas, porque essa é a sua vantagem contra empresa grande. E arrume algum segundo fator, nem que seja um amigo que lê seus planos e fala "isso aqui tá estranho".
E se você quiser ver de perto o que eu ando construindo, baixa a Lobbix+ na App Store ou no Google Play. Começa avaliando Indie Game: The Movie e Silicon Valley, e me chama por lá: eu sou o @gabrielpafer.
