A história mais triste de "Just Ship It" (2020)

• O side project iniciado em 2018 teve um MVP pronto em poucos dias, mas, ao continuar adiando o momento de lançar, acabou virando um projeto de 2 anos sem lançamento
• No centro do atraso estava a decisão repetida de “só mais uma coisinha”, e o escopo do produto cresceu até incluir o aprendizado de React Native e Expo
• O app concorrente que resolvia o mesmo problema era lento e tinha bugs, mas já estava lançado, ganhando usuários e comunidade e melhorando toda semana
• Depois do teste de 30 dias, ao pagar pelo app concorrente, seu próprio app — que só existia no disco rígido — se tornou na prática um produto morto
• Na atualização de 2024, ele conta que finalmente lançou o app de produtividade Benji em 2022, e que, por mais batida que seja a conclusão, ela continua apontando para lançar primeiro

---

Por que ele não conseguiu lançar por 2 anos um MVP feito em poucos dias

• Em 1º de janeiro de 2018, começou o desenvolvimento do app, e o MVP ficou pronto em poucos dias
• A versão alfa 0.0.1 já estava em condição de ser publicada, mas o lançamento era sempre adiado com justificativas como “só mais uma funcionalidade” e “só mais uma tela”
• Ao concluir que “sem um aplicativo mobile nativo de verdade as pessoas não vão usar”, decidiu aprender React Native e dedicar mais alguns meses a isso
• Depois disso, por 2 anos, houve repetição de trabalho na plataforma web, React Native, Expo, GraphQL, dúvidas sobre a stack, mudança para outros projetos, lançamento de outros apps como Sizzy, perda e recuperação de motivação
• No fim, ele parou o desenvolvimento e também abandonou a ideia de lançar aquele app

O momento em que encontrou um app resolvendo o mesmo problema

• Com o tempo, ao continuar usando o próprio app, percebeu que precisava de muitas funcionalidades e voltou a uma situação em que precisava retomar o desenvolvimento ou encontrar uma alternativa
• Ao ver a landing page de um app alternativo, sentiu com força que alguém já havia resolvido exatamente o problema que ele queria resolver
• Como já tinha enviado antes um vídeo do seu app para algumas pessoas, chegou a suspeitar que o vídeo tivesse sido compartilhado, tamanha a semelhança entre as funcionalidades e a visão do problema
• Mas entendeu que a existência do concorrente não era culpa deles, e sim porque ele próprio foi lento demais e não lançou na hora certa

O concorrente colocou o lançamento à frente do acabamento

• Ao criar uma conta e assistir aos vídeos da central de ajuda, sempre que achava a implementação inteligente também se lembrava de que estava olhando para um concorrente
• Durante 2 anos, pensou que seu app era desajeitado, cheio de bugs e incompleto demais para que alguém o usasse, mas, ao testar o concorrente, percebeu que esse julgamento estava errado
• O app concorrente também vinha sendo desenvolvido havia anos, mas ainda era lento, tinha bugs e estava longe de estar totalmente polido
• O app mobile era ruim a ponto de levar 10 segundos para sincronizar, mas já era um produto lançado, e os usuários podiam esperar pela próxima atualização
• Mesmo com uma lista enorme de tarefas, eles continuavam lançando toda semana, e o app e a comunidade cresciam juntos

A lição que restou depois de pagar

• Depois que o teste de 30 dias acabou, ele inseriu os dados do cartão de crédito e deixou de ser apenas assinante: virou fã
• A notificação de pagamento ficou marcada como uma experiência que o fazia lembrar repetidamente que ele não tinha conseguido lançar
• Foi nesse momento que aceitou que seu app estava oficialmente morto
• A maioria das pessoas na mesma situação talvez ainda esteja só nas primeiras semanas do projeto, então é preciso evitar o mesmo erro
• Se o “só mais uma coisinha” significa refazer autenticação, pagamentos e boilerplate, então isso é uma armadilha; para reduzir essa armadilha, depois ele criou o Zero To Shipped

Atualização de 2024: Benji finalmente foi lançado

• Segundo a atualização de 2024, ele finalmente lançou o Benji em 2022
• O motivo do lançamento foi que nenhum app concorrente chegava perto o suficiente da visão que ele tinha
• O app que ele queria era uma combinação de Todos, Habits, Planner, Goals, Pomodoros, Meal tracking, Fasting, Hydration, Packing e Trips
• O Benji também tem uma timeline pública onde as pessoas melhoram suas vidas e compartilham sucesso e conquistas
• Mesmo que soe clichê, é preciso respirar fundo e ainda assim Just Ship It

[GN⁺]

Opiniões no Hacker News

• Há uma grande pista nessas histórias do tipo “acabou porque não lançamos logo naquela hora”: às vezes o valor do app que estava sendo feito está em detalhes técnicos que não podem ser apressados, e nesses casos “simplesmente lançar” não é a resposta.
  O trabalho de um engenheiro/arquiteto de software também é resistir, tanto quanto possível, à pressão da diretoria de “só coloca no ar”. Se não é um produto que você possui diretamente e o lançamento não vai beneficiá-lo pessoalmente, então, se gastar mais tempo produzir um resultado mais profissional, é preciso gastar esse tempo. Você não é uma máquina automática que recebe tickets no JIRA e cospe código malfeito o mais rápido possível; se continuar trabalhando assim, vai se desgastar mentalmente e acabar em burnout.
  Se você não tem participação na empresa, seu trabalho não é maximizar o lucro dela, e sim criar bom software que você não tenha vergonha de colocar no currículo. O alívio de cumprir mais um prazo arbitrário é apenas uma motivação negativa de curto prazo e não dura; por isso é preciso resistir à pressão que vem de cima e fazer direito. Mesmo que seja demitido, hoje em dia trocar de emprego já é, de qualquer forma, o caminho para subir.

  • “Se você não tem participação na empresa, não precisa se preocupar com lucratividade” me parece uma atitude ruim que revela falta de senioridade de um desenvolvedor de software. Se não for uma organização sem fins lucrativos, todos na empresa devem contribuir para a lucratividade.
    Dito isso, lucratividade não é sinônimo de “simplesmente lançar”. Se uma empresa confunde essas duas coisas com frequência, é sinal de falta de senioridade do lado da gestão.
    O trabalho do desenvolvedor está mais perto de criar um bom produto do que de criar “bom software”. Um bom produto geralmente precisa de bom software, mas nem sempre; e há muitos casos de software péssimo por trás de produtos excelentes. A tensão entre produto, vendas e desenvolvimento deve levar a compromissos que maximizem valor no curto, médio e longo prazo; o desenvolvedor precisa entender o que pode ser feito de qualquer jeito, quais prioridades a empresa tem e quando não se deve fazer concessões, mas sim construir bom software.
    Um desenvolvedor que nunca aceita comprometer a qualidade do software perde força justamente nos momentos em que realmente não se deve ceder.
  • É preciso olhar primeiro para o motivo de desenvolver. Pode ser por hobby, diversão ou pela beleza do código, mas na maioria dos casos é para fazer o software executar uma tarefa de que alguém precisa.
    Portanto, a prioridade número 1 é criar valor para o usuário e desenvolver da forma mais eficiente possível. Que sentido tem um software que ninguém usa?
    O trabalho do desenvolvedor não é criar bom software, mas entregar valor ao usuário. Na minha carreira, o que vi com mais frequência foi justamente desenvolvedores se embriagando com overengineering, inchando o código com funcionalidades de que ninguém precisa e aumentando o código para se preparar para desenvolvimentos futuros que talvez nunca venham. Por isso, a tarefa difícil é permanecer minimalista, e o texto original parece falar disso.
  • Este comentário inteiro soa como se a pessoa enxergasse a relação com os colegas de forma puramente adversarial e tivesse pouquíssima confiança. Parece bem exaustivo.
  • Fui um dos primeiros funcionários de uma startup, e se não tivéssemos feito concessões, é bem provável que a empresa nem existisse hoje. Essa abordagem só funciona em grandes empresas estabelecidas, onde a influência da equipe sobre o resultado é limitada.
    Em empresas pequenas e médias, concessões são definitivamente necessárias, e fazer escolhas que levem ao melhor resultado de negócio também faz parte do trabalho de um profissional.
    Muitos desenvolvedores são “protegidos” por várias camadas de gerentes, PMs e designers, então têm pouca conexão com o lado do negócio. Lançar o produto rápido também traz feedback rápido e cria oportunidades para avaliar se a implementação corresponde às hipóteses. Achei menos estressante do que implantar uma solução “perfeita” sob pressão e depois ter de reescrevê-la.
    No meu emprego atual, o que faço como desenvolvedor é reduzir complexidade e fazer PMs e designers enxugarem ao mínimo seus planos iniciais. Assim, prazos arbitrários também ficam menos estressantes e o impacto de atrasos diminui.
  • Parece sátira. Vêm uma sequência de frases marcantes, como “se não é seu trabalho, faça a coisa errada; se é seu trabalho, lance rápido” e “seu trabalho é colocar algo no currículo e se sentir bem”.
    A parte valiosa é algo como não se apegar demais a um emprego específico e não se preocupar excessivamente em ser demitido, mas acho que até a explicação para isso está errada. É surpreendente pensar que posso estar trabalhando de fato com pessoas que têm essa atitude adversarial.
    Algumas pessoas parecem gostar de viver no quadrante errado da teoria dos jogos.

• Ao ler a parte “suspeitei que alguém tivesse compartilhado o vídeo do meu app com essas pessoas, porque estavam literalmente resolvendo o mesmo problema”, lembrei de quando conheci uma pessoa que tinha uma boa ideia de app.
  Ele pediu que eu codificasse o app de graça e propôs dividirmos a receita. Quando perguntei o que ele contribuiria, respondeu que iria “operar” a empresa e que seus 50% eram “porque teve a ideia”. Então eu disse que daria a ele seis meses de vantagem e que, se até lá ele não colocasse no mercado, eu mesmo o faria.

  • Participei certa vez de um projeto de jogo indie. Era uma ideia comum, quase um jogo ruim, mas nós três queríamos experiência em desenvolvimento de software naquela área.
    Dois de nós simplesmente sentaram e começaram a dar forma ao projeto, mas o terceiro subiu código quebrado no SVN, criou um documento de design atribuindo a si o crédito por toda a ideia e então convocou uma reunião para dizer que ele era o game designer e que nos processaria se fizéssemos o jogo em outro lugar. Os dois que de fato estavam contribuindo se olharam e encerraram o projeto. Ele mostrou todas as cartas, e percebemos que não era grande coisa.
    Mais tarde vi na Steam um jogo com uma ideia parecida. Se eles chegaram à ideia de forma independente, ótimo; se roubaram daquele perdedor, também ótimo; e, se aguentaram trabalhar até o fim sob aquele sujeito, merecem o dinheiro.
  • Como alguém extremamente inclinado para lógica e programação, eu até gostaria de conhecer uma pessoa assim. Acho que eu mesmo não sou do tipo das ideias.
    Se a ideia fosse realmente boa e confiável, honestamente poderia ter sido uma proposta bem razoável.
  • Cuidar de vendas, marketing, contabilidade e todo o resto necessário para operar uma empresa vale 50%, talvez até mais. Mas, embora seja bem provável que a pessoa que codificaria fosse suficientemente competente, parece baixa a chance de ele ser competente o bastante para “operar” a empresa.
  • Não sei se é sensato dizer algo assim quando você não conhece completamente o estado mental da outra pessoa.
    Se você acha que pode dizer a alguém “daqui a seis meses vou roubar sua ótima ideia”, é bom torcer para que essa pessoa não seja do tipo que possa causar problemas ou, em casos extremos, causar algum dano.

• Eu gostaria que alguém resolvesse meu problema por mim. O motivo de eu estar preso a ele agora é simplesmente que não existe uma solução pronta que eu possa comprar e usar
  Se alguém suasse a camisa para resolver meu problema e ainda assumisse o on-call e a manutenção, eu ficaria feliz
  Por que necessariamente você precisa resolver esse problema? Por que necessariamente a sua solução precisa ser um negócio? Um negócio é criar valor para você e para os clientes. Se você está obcecado pelo problema em si, deveria agradecer quando outra pessoa dedica muito esforço para resolvê-lo; se estivesse obcecado pelos clientes, já deveria ter colocado algo nas mãos deles há muito tempo para obter feedback

  • Parece que alguns desenvolvedores solo querem implementar uma ideia nova, transformá-la em um negócio com algum sucesso, dominar o mercado e depois vendê-la a uma empresa maior por muito dinheiro
    Talvez não haja muita gente que queira tocar uma empresa no longo prazo, mas a maioria provavelmente não se incomodaria de receber muito dinheiro de repente por ter resolvido ou abordado um problema interessante
  • Sou o autor original: isso era importante para mim porque um app que eu usava havia ficado estagnado por um tempo e não recebia mais atualizações. À medida que aprendi mais sobre produtividade, cheguei aos limites daquele app e queria mais recursos
    Eu continuava tendo ideias para colocar no meu app, mas outros desenvolvedores provavelmente não teriam interesse em implementá-las. Eu queria controle, e por isso acabei lançando o Benji: https://benji.so

• Sou o autor original. Preciso atualizar este texto. Alguns anos depois, eu realmente me motivei com os comentários no HN toda vez que este texto aparecia
  As pessoas sempre perguntavam “por que você simplesmente não lança o app?”, então acabei lançando
  Fico feliz por ter ido até o fim, e acho que ele é muito melhor do que qualquer concorrente dessa categoria
  Dá para ver em https://benji.so. A landing page ainda está em andamento

  • A landing page está deixando o navegador engasgado. É uma tela inicial com algumas imagens; não sei como isso é possível. O que diabos essa página está fazendo?
  • Passei por um ciclo parecido de desenvolvimento de app sem conseguir lançar. Comecei com React, depois mudei para React Native e Flutter, e no fim também migrei de GraphQL para SQLite
    Meu app tinha um objetivo parecido, conectando motivação de hábitos, medição de cumprimento de metas e agendamento e reagendamento de tarefas. Trabalhei nele por alguns anos, e a ideia de um dia transformá-lo em uma empresa bootstrap ficou muito ligada à minha identidade
    A decisão de largar o projeto veio em várias etapas, mas um dos grandes fatores de encerramento foi perceber que eu não queria viver como desenvolvedor de apps no longo prazo. Foi difícil soltar, mas hoje estou satisfeito com essa decisão. Como no texto original, dá para dizer que “nada desaparece completamente”, já que talvez ele possa ressuscitar no futuro, mas não acho que vou voltar a este projeto específico
    Uma das ideias centrais para superar a “alta carga cognitiva” da maioria dos apps de produtividade era um marketplace de módulos de vida. Por exemplo, um influenciador de fitness venderia um pacote com rotina de exercícios, dieta e templates de diário, e o usuário “instalaria” aquilo na própria vida
    Modelos de linguagem grandes tornarão muito mais viável detectar abandono, inferir causas ou reagir a “ações não realizadas”. Acho isso importante para pessoas que não têm personalidade tipo A e não usam um app de produtividade de forma consistente todos os dias
  • Acabei de testar, e o nome do fuso horário detectado apareceu como “Africa/Ceuta (Romance Standard Time) (UTC+01:00) Brussels, Copenhagen, Madrid, Paris”
    A diferença em relação ao GMT está correta, mas Brussels, Copenhagen, Madrid, Paris não ficam na África, então isso é muito confuso. Seria bom conferir as informações de fuso horário que vocês estão usando
    Vendo o comentário abaixo, isso não era um problema
  • Os links brancos do menu sobre fundo branco não aparecem. Deixo o aviso, caso seja útil: https://i.imgur.com/Yd1hniV.png
  • Parece bom. Talvez eu teste. O nome veio deste amigo aqui https://en.wikipedia.org/wiki/Benji? Eu gostava muito dele quando tinha uns 6 a 8 anos
    E desculpe por ter expressado frustração e desconfiança por você não dizer o nome do “concorrente”. Agora que você lançou seu próprio app, a chance de dizer o nome daquele concorrente, mesmo que ele ainda exista, parece ainda menor

• Tornar-se um usuário real do próprio sistema muda completamente a perspectiva. Eu também estava criando algo para mim e achava que não estava pronto e era totalmente inutilizável
  Depois de abandonar o projeto, decidi usá-lo como um usuário real e percebi que usuários se acostumam a inúmeros probleminhas e encontram desvios automaticamente. Quem cria algo muitas vezes esquece que muitas imperfeições não são impeditivas, e que os usuários contornam várias deficiências sem grande esforço. Nesse ponto, a busca pela perfeição vira quase uma questão de orgulho
  Ignorar por um tempo o fato de que você foi quem criou aquilo e usá-lo de verdade, proibindo-se inclusive de fazer correções por um período, pode mudar tudo

  • Por isso acho que “lance e itere rapidamente” costuma ser o melhor caminho. Qualquer projeto de software pode ter bugs críticos. Se um pacote de contabilidade não faz a contabilidade direito, claro que não deve ser lançado; mas se um relatório aparece duas vezes por algum motivo, os usuários conseguem lidar com isso até a próxima iteração. Desde que essa próxima iteração não venha meses ou anos depois
    Na prática, você não vai encontrar a maioria dos “bugs” que os usuários vão enfrentar até colocá-lo diante de usuários reais. Se você não lançar, também não terá a chance de corrigir os bugs que realmente afetam os usuários
  • Um app que acabei de usar tinha um navegador web embutido do iOS que não funcionava direito
    Simplesmente abri a página web diretamente, e o nome de usuário e a senha obviamente estavam sincronizados pelo iCloud. Levei 5 segundos para retomar o fluxo do usuário no Safari e só 30 segundos para terminar

• Não é o melhor exemplo de “simplesmente lance”. Categorias como apps de produtividade, tarefas, acompanhamento de hábitos, controle de gastos, diário e planos de treino são áreas em que muita gente chega à mesma ideia de forma independente
  Vocês não fazem ideia de como me senti inteligente quando tive a ideia de um app para registrar gastos. Aí fui verificar a Play Store. A KRAZAM também tirou sarro disso há 5 anos no vídeo “The Hustle”

  • Essa talvez seja a categoria mais exageradamente saturada da história das categorias de apps exageradamente saturadas
    Isso não quer dizer que uma nova variação não possa dar certo. Afinal, a maioria dos sucessos não é totalmente original. Mas, se você está preocupado que alguém lance primeiro a própria versão e ganhe, basta dar uma olhada ao redor
  • A parte de “verifiquei a Play Store” parece perder o ponto central do texto. O ponto é lançar mesmo que existam concorrentes. Na verdade, concorrentes são um bom sinal de validação da ideia, não um mau sinal

• Pessoalmente, não suporto esse estilo de escrita que “se esforça demais para ser engraçado”

  • Concordo. É bem cansativo de ler. Uma ou duas ironias bem colocadas tudo bem, mas em excesso não dá
  • Não é só você; e tudo bem pessoas terem gostos diferentes

• Desisti no meio. Infantil e constrangedor demais
  No fim, eles só fizeram uma prova de conceito e se acomodaram nela. É uma pena, mas a vida é assim. Eles fizeram o trabalho e colheram a recompensa
  A lição é que ideias não podem ser possuídas

• Concordo totalmente com isso. Quando começamos o Kviklet, éramos 3 pessoas, e uma delas era muito mais perfeccionista que as outras duas. Sinceramente, até colocar no ar a primeira versão do site, que era péssima, exigiu muita persuasão, e abrir o repositório foi ainda mais difícil
  Esse “cofundador” saiu no começo, mas fico muito feliz por termos lançado cedo e tentado vender
  Não deu muito certo e não encontramos comprador, mas é horrível imaginar que ainda estaríamos construindo o produto no escuro, nos agarrando só à esperança, sem saber se alguém pagaria por ele
  Agora transformamos em open source como plano B e conseguimos alguns usuários bem legais. Acho que dá até para chamar de uma pequena comunidade: https://github.com/kviklet/kviklet
  Não é a história de sucesso de startup que eu esperava há 1 ano, mas é muito melhor do que continuar apenas na expectativa, sem senso de realidade. E ser open source não significa que não dê para ganhar um pouco de dinheiro vendendo suporte ou uma versão premium, não é? Por enquanto, é só um projeto paralelo divertido

  • A descrição “um fluxo de revisão/aprovação tipo Pull Request para consultas de banco de dados” não é boa. Não deveria passar a sensação de que queries precisam de aprovação
    Deveriam usar palavras como mutation, edit, update, modification. Mesmo que query esteja tecnicamente correto, em termos de conotação soa errado e confuso

• Se estou criando algo para mim mesmo, não vou ficar triste porque alguém fez antes. Isso só prova que a ideia era boa
  Claro, muitos projetos pessoais que estão na minha cabeça e no papel, e até alguns que eu realmente comecei um pouco, não são coisas que pretendo lançar para vender. São coisas que eu quero ou que amigos, família ou outras pessoas poderiam achar úteis
  Se eu tiver algo em qualidade alfa, talvez eu publique esperando que alguém pense “a ideia é útil, mas a implementação é ruim; vou fazer melhor”

  • Na prática, em quase todas as situações alguém ou alguma coisa já chegou antes. Mesmo quando você está automatizando algo pela primeira vez na história, o processo manual existente é seu concorrente inicial. O app do texto também compete não só com outros apps, mas com todo tipo de combinação de soluções parciais que o público-alvo já usa
    Além disso, mesmo sendo o primeiro a entrar, logo surgirão concorrentes que vão corroer sua vantagem, e será preciso continuar se esforçando para ficar à frente
    Então, se de qualquer forma sempre há alguém antes, e a concorrência é certa agora ou depois, não adianta se preocupar em ser ultrapassado; foque na vantagem competitiva. Parece que o autor original acabou chegando a essa percepção, e torço para que dê certo