Construir nunca foi o gargalo — mas fazia outros três trabalhos (2026)

Três cartões empilhados com os subprodutos que a construção barata eliminou: o filtro de ideias, o sinal de confiança e a compreensão, cada um junto de um dos tópicos mais votados do Reddit

Na maioria das semanas leio os tópicos de maior destaque do r/SaaS e do r/startups. Normalmente são uma mistura: um lançamento, uma análise de cancelamentos, os primeiros 9 dólares de alguém. Esta semana não. Três tópicos diferentes, de três pontos de vista completamente distintos, acabaram por descrever a mesma coisa sem que nenhum deles desse por isso.

Um construtor escreveu que consegue lançar qualquer coisa e não encontra uma única ideia que valha a pena lançar. Uma pessoa empregada numa empresa escreveu que, quando um fornecedor se gaba de ter construído algo num fim de semana, o que ouve é um aviso. E um consultor cujo negócio é agora salvar produtos feitos com vibe coding contou como viu um fundador com oitenta clientes pagantes abrir a sua própria app e clicar por todo o lado para descobrir o que acontecia quando alguém cancelava a meio do mês.

Lidos separadamente, são um problema de ideias, um problema de marketing e um problema de qualidade. Lidos em conjunto, são um só problema, e não é aquele a que as secções de comentários chegaram.

Os três tópicos

Eis o que cada um disse de facto, antes de lhe acrescentar qualquer interpretação.

Tópico	Escrito por	Pontos	Comentários
«Estou farto dos fundadores do "construí isto num fim de semana com IA"»	Um funcionário do lado do comprador	306	102
«Consigo construir quase tudo. Não encontro uma única ideia de SaaS que valha a pena»	Um construtor forte	129	200
«Consigo construir tudo. Não faço ideia de como fazer as pessoas se importarem»	Um fundador que lançou sem eco	84	108
«O maior problema do vibe coding não é a segurança»	Um consultor de resgates	81	51

Dois deles são a mesma frase escrita por duas pessoas diferentes, em dois subreddits diferentes, em dois dias diferentes: consigo construir tudo. Ninguém a contestou em nenhum dos dois tópicos. O desacordo era apenas sobre o que vem a seguir, e os principais comentários dividiram-se com clareza entre «tens um problema de ideias» e «tens um problema de distribuição», com um terceiro grupo recorrente a insistir que não, na verdade construir continua a ser a parte difícil e quem diz o contrário é que o faz mal.

Os três grupos descrevem um sintoma. O que têm em comum é mais útil.

O que foi realmente eliminado

Construir software era lento e caro. Toda a gente concorda que isso era mau, e na maior parte dos casos era. Mas a lentidão fazia três trabalhos além de produzir o software, e fazia-os de forma invisível, de graça, quisesse ou não.

Filtrava as suas ideias. Sinalizava a sua maturidade aos compradores. E ensinava-lhe o que o seu próprio produto fazia.

A IA eliminou o custo. Não substituiu os três subprodutos. É essa a forma de todas as queixas desta semana, e é por isso que os conselhos nos comentários continuam a falhar: não se resolve um subproduto em falta trabalhando mais na coisa que antes o produzia.

Subproduto um: o filtro de ideias

Quando uma construção lhe custava seis meses ou noventa mil dólares, não podia ter trinta ideias. O custo fazia a seleção por si. Escolhia aquela que conseguia defender perante si próprio às duas da manhã, e o simples peso do compromisso forçava um nível de escrutínio que parecia discernimento mas era sobretudo medo.

Tire-se o custo e vai com ele o mecanismo que obrigava a escolher. O construtor daquele tópico descreveu o seu ciclo com precisão: fazer um brainstorming, chegar a algo engenhoso, descobrir que dez empresas já o fazem ou que ninguém o procura, construir uma versão rápida, perceber que não entende de todo os utilizadores, repetir. Chamou ao resultado um cemitério de coisas engenhosas meio construídas. O notável é que ele próprio fez o diagnóstico certo: escreveu que inventa ideias a partir da cadeira em vez de as roubar a um problema dentro do qual vive.

Isso está exatamente certo, e vale a pena ser preciso sobre porquê. Construir é a parte confortável. Tem uma definição de terminado, produz progresso visível, e ninguém lhe diz que não enquanto o faz. Chegaram duzentos comentários a dizer-lhe para falar com clientes, e ele já sabia. A razão pela qual os fundadores se escondem na construção não é a ignorância. É que construir é a única parte do trabalho que recompensa o esforço com resultados de forma fiável, e quando não custa nada pode esconder-se lá indefinidamente.

O comentário mais certeiro do tópico reformulou a procura por completo. Não faça um inventário de problemas, defendia — faça um inventário de irritações. Não «o que falta», mas o que as pessoas toleram em silêncio e nunca mencionam, porque não lhes parece um problema real. Os vinte minutos de apreensão antes de uma reunião de revisão com um cliente. A folha de cálculo que alguém refaz todas as segundas-feiras. Isso nunca aparece numa análise da concorrência, porque nada está tecnicamente avariado. É aí que vive de facto a disponibilidade para pagar.

Subproduto dois: o sinal de confiança

É este o subproduto para o qual os fundadores estão menos preparados, porque não desapareceu: inverteu-se.

Os compradores nunca tiveram forma de inspecionar a sua engenharia. O que tinham era um indicador indireto: o software meio construído parecia meio construído. Arestas por limar, estados em falta, uma página de definições feia — tudo isso indicava mais ou menos quanto trabalho faltava, e os compradores liam-no com fluência sem nunca formularem que o estavam a fazer. O acabamento era o recibo de ter sobrevivido aos casos-limite.

Agora, o invólucro com ar de terminado chega no primeiro dia. O indicador partiu-se, e o mercado fez o que os mercados fazem quando um sinal se parte: substituiu-o por um mais grosseiro. O post de 306 pontos é essa substituição dita em voz alta. O autor, uma pessoa empregada a quem deixam ferramentas na secretária com ordens para as integrar no trabalho, enumerou aquilo por que a sua empresa paga de facto — que ainda lá esteja no sexto mês, que não perca os nossos dados, que a coisa faça o mesmo de cada vez — e depois disse a frase com que todo o tópico concordou: pare de se gabar da velocidade, porque para quem lhe paga isso soa a aviso.

A ressalva honesta

Uma grande parte dos comentários acusou o post de ser isco de interação gerado por IA, e pediu ao autor que nomeasse um único produto real que lhe tivesse falhado. Podem perfeitamente ter razão. Mas isso não é razão para descartar o tópico — é o mesmo fenómeno uma camada acima. A acusação pega porque um resultado com ar polido já não certifica esforço em lado nenhum, nem sequer num post do Reddit. O indicador de confiança partiu-se ao mesmo tempo para o software e para a prosa, pela mesma razão.

A consequência prática é que a velocidade deixou de ser um trunfo de marketing e passou, sem alarde, a ser um passivo que tem de compensar. Nada no seu texto de lançamento deve começar pela rapidez com que o construiu. O que os compradores procuram agora são provas de duração e de consequência: há quanto tempo está a funcionar, o que acontece quando algo avaria, quem responde, se os dados deles sobrevivem a uma má versão. Um fundador do tópico propôs uma métrica que vale a pena copiar: conte quantas conversas de suporte são o mesmo problema a voltar uma segunda vez. Não o volume de tickets. As repetições. É uma leitura implacável de que partes do seu produto se aguentam com fita-cola, e não quer saber da rapidez com que as lançou.

Subproduto três: a compreensão

O tópico do consultor de resgates é o mais valioso dos quatro e o que recebeu menos atenção, como costuma acontecer.

A história: um fundador levou um produto de reservas que tinha feito com vibe coding em alguns fins de semana. Era genuinamente bom, polido, com cerca de oitenta clientes pagantes. Depois, um cliente perguntou o que acontece à parte não usada de um plano quando se cancela a meio do mês, e o fundador abriu o seu próprio produto e clicou por todo o lado para descobrir. Não ficou envergonhado. Para ele, é simplesmente assim que se descobre o que o produto faz.

A forma como o consultor explica porque é que isto é diferente da dívida técnica é a parte a reter: a dívida pressupõe que alguém consegue ler as contas. Aqui, no momento em que um cliente contesta um valor, o fundador tem de alterar um comportamento que nunca percebeu, e nenhuma refatoração fecha essa lacuna, porque a lacuna nunca esteve no código. Os comentadores convergiram em chamar-lhe dívida de compreensão.

O mecanismo merece ser descrito com cuidado, porque não é «a IA escreve mau código». O código estava bom. O que aconteceu foi que uma decisão foi tomada e ninguém sabia que uma decisão estava a ser tomada. Alguém — alguma coisa — tinha de decidir o que um cancelamento a meio do ciclo faz a um saldo proporcional. O modelo decidiu, com confiança, de uma forma que parecia plausível no ecrã, e o fundador nunca viu um ponto de decisão. Como o consultor disse num comentário posterior: escreva primeiro as decisões, ou o modelo toma-as por si.

O diagnóstico dele é a coisa mais prática de qualquer dos quatro tópicos, e leva cerca de vinte minutos:

O teste das cinco perguntas

Escreva as cinco perguntas mais difíceis que um cliente poderia fazer sobre o comportamento do seu produto. Responda-lhes sem abrir a app. As que não conseguir responder são as partes do negócio que ainda não são suas.

Mais um pormenor do mesmo tópico, de alguém que fez vários destes resgates: na faturação há normalmente três versões da verdade a circular — o que está no código, o que está no Stripe, e o que o fundador tem dito às pessoas nos emails de suporte. Pôr essas três de acordo é o resgate, na maior parte das vezes. O trabalho de código que vem depois é a parte fácil.

Porque é que os conselhos de distribuição continuam a falhar

O fundador do r/startups — o produto funciona, alguns utilizadores adoram-no, não faz ideia de como fazer alguém importar-se — recebeu 108 comentários, e a maioria dizia o mesmo em poucas palavras: encontra vinte pessoas. É um bom conselho e não o ajudou, e a razão foi apontada por um comentador com uma precisão invulgar: a maioria dos fundadores não consegue dizer quem são essas vinte pessoas. Não o setor, não a persona. A situação concreta que faz alguém precisar disto hoje e não no próximo trimestre.

A diferença entre «pessoas de operações em empresas SaaS» e «pessoas de operações que acabaram de contratar o primeiro SDR e perceberam que não têm processo» é a diferença entre um canal que se pode ir procurar a frio e uma categoria onde só se pode anunciar. Tudo o resto — texto, canal, momento — é secundário.

Houve também uma boa resposta à verdadeira objeção do fundador, que era que publicar lhe parece estar a atuar e que o faz mal. Dois comentadores, de forma independente: pare de difundir e comece a responder. Vá onde o problema é discutido e responda a perguntas, a maioria sem nada a ver com o seu produto. Responder não é subir a um palco. E, em separado, pergunte ao punhado de pessoas que já usam o que faz em que tópico, fórum, Slack ou subreddit estavam no momento em que o problema as irritou o suficiente para irem procurar. Isso dá-lhe três sítios reais em vez de uma estratégia de conteúdos.

Recuperar os subprodutos

Se o diagnóstico é que três coisas que antes recebia de graça têm agora de ser compradas de propósito, então o trabalho é agendar cada compra. Em concreto:

Substitua o filtro do custo por um filtro de evidências. Escolha um grupo de pessoas a que consiga chegar de facto, e reúna dez momentos recentes em que pagaram por algo, esperaram por algo ou montaram uma folha de cálculo à volta disso. Dez momentos concretos, com data e nomes. Se não encontrar dez, essa é a resposta.
Venda primeiro a versão manual. Ofereça a solução mais pequena, feia e feita à mão antes de escrever software. Se ninguém lhe der tempo ou dinheiro pela versão feia, um código melhor não a salva. É o único mecanismo restante que não custa nada pôr a funcionar e que ainda diz que não.
Escreva o comportamento antes de o construir. Uma tabela curta — faturação, cancelamento, reembolsos, permissões, recuperação de falhas — com o resultado pretendido em cada linha e uma verificação executável. Não é documentação escrita depois; é o conjunto de decisões que, de outro modo, o modelo vai tomar em silêncio por si.
Faça o teste das cinco perguntas ao que já lançou. Hoje, antes que um cliente o faça por si. Cada pergunta a que não consiga responder de memória é uma decisão que não controla.
Acompanhe as conversas de suporte repetidas, não o volume de tickets. Uma taxa de repetição a subir é o sinal honesto mais precoce de que uma parte do seu produto nunca ficou realmente terminada, por muito terminada que pareça.
Comunique duração, não velocidade. Disponibilidade, histórico de incidentes, tempos de resposta, há quanto tempo está a funcionar, o que acontece aos dados no cancelamento. É a prova que os compradores usam agora em vez do sinal que se partiu — e é a única parte do discurso que um concorrente não consegue gerar num fim de semana.
Nomeie o gatilho, não a persona. Escreva a frase que descreve a situação concreta que faz alguém precisar disto hoje. Se não conseguir, nenhum canal o vai salvar, porque o canal nunca foi o problema.

A leitura

As secções de comentários passaram a semana a discutir se a parte difícil é construir, ter ideias ou vender. É uma má discussão, porque a resposta está sempre a mudar e nunca foi a pergunta interessante. A pergunta interessante é o que um custo estava a pagar em silêncio antes de desaparecer.

Seis meses de construção compravam-lhe uma ideia filtrada, um produto credível e um modelo mental funcional do seu próprio negócio. Pagava por uma coisa e recebia quatro. Agora não paga nada e recebe uma, e as outras três têm de ser adquiridas de propósito, por pessoas que na sua maioria não sabem que lhes faltam.

É essa a verdadeira competência de um fundador em 2026. Não o prompting, não a velocidade de lançamento — perceber quais dos seus antigos subprodutos gratuitos deixaram de chegar, e ir comprá-los de volta antes que um cliente descubra que nunca os teve.