Build vs buy: o framework de decisão para fundadores não-técnicos

Build vs buy raramente é a pergunta certa. Aqui está um checklist de quatro perguntas que fundadores em early-stage conseguem rodar em quinze minutos antes de assinar um contrato SaaS, contratar um dev, ou abrir um doc no Notion chamado “spec do MVP.”

O fundador na call comigo tinha uma pergunta limpa e uma resposta confusa. Tinha levantado uma rodada seed oito meses antes, fechado dois pilotos enterprise, e estava agora olhando para uma planilha com onze assinaturas SaaS em cima. “Acho que a gente precisa construir o nosso próprio,” ele disse. “Ou talvez consolidar. Não sei qual dos dois. Sinceramente, nem sei como decidir.”

Conversamos uma hora. Ele, na real, não tinha formulado a pergunta certa. Achava que estava decidindo entre software sob medida e SaaS. A árvore de decisão real era mais larga, suas restrições mais apertadas do que ele percebia, e a resposta para “build ou buy” dependia quase inteiramente de três variáveis que ele ainda não tinha nomeado em voz alta. Saiu da call com um checklist de quatro perguntas. Duas semanas depois cancelou quatro das onze ferramentas, contratou mais duas, e colocou exatamente um workflow na lista de build.

Essa conversa, em alguma forma, acontece na Pixel Breeders quase toda semana. A pergunta de build vs buy é a decisão mais comum que um fundador não-técnico nos traz. Também é a mais consistentemente mal formulada.

Esse é o framework que a gente usa.

O que “build vs buy” significa de verdade

Build vs buy é a decisão entre construir um software sob medida para um workflow e comprar um produto pronto que resolve um problema parecido. O enunciado clássico é binário: escrever o código você mesmo (build), ou pagar um fornecedor por software pronto (buy).

Em 2026, o enunciado já está errado antes mesmo de você começar. Existe uma terceira opção que, silenciosamente, atende a maioria dos workflows de empresas early-stage: costurar algumas ferramentas SaaS com cola no-code (Zapier, Make, n8n, Airtable, um Retool em cima). Não é build puro nem buy puro. É a realidade default de quase toda startup pré-Série A com quem a gente trabalha, e ignorar essa opção produz decisões ruins.

Então a pergunta real é:

• Build: software sob medida escrito para o seu workflow específico.
• Buy: um produto pronto que dá conta do workflow ponta a ponta.
• Stitch: juntar dois ou mais produtos existentes com uma cola leve (automações, formulários internos, um dashboard).

A maioria dos fundadores cai no buy por default, às vezes gasta demais no stitch, e subestima o quanto build raramente é a resposta certa para o estágio deles. As quatro perguntas abaixo são desenhadas para fazer aflorar qual das três realmente serve.

As quatro perguntas

Rode na ordem. Cada uma é um portão. Se uma pergunta mata a opção de build, pare ali. Você não precisa fazer a próxima.

1. Esse workflow é central para como a gente ganha dinheiro?

O primeiro portão é se o workflow é estrutural para a receita.

Um workflow é central se for um dos seguintes:

• Uma superfície de produto que seus clientes pagantes tocam diretamente.
• Um workflow que seu time executa milhares de vezes por mês e que tem efeito mensurável sobre conversão, retenção, ou unit economics.
• Um workflow regulatório ou de confiança crítica (KYC, custódia, sinistros) onde uma indisponibilidade ou limitação de fornecedor machucaria o negócio de forma relevante.

Um workflow não é central se for coordenação interna (gestão de projeto, agenda, despesas), comunicação inicial com cliente (CRM, e-mail), ou qualquer coisa onde “bom o suficiente” ganha de “exatamente do meu jeito.”

Se o workflow não é central: buy ou stitch. Você não deveria estar construindo software para problemas que são resolvidos de forma adequada por um produto de $40 por usuário que 50.000 outras empresas estão usando. A vantagem que você tira de uma ferramenta genérica é real, o tempo economizado é real, e o custo de manutenção de uma versão sob medida composta contra você por anos.

Se o workflow é central, vai para a pergunta dois.

2. Algum produto de prateleira realmente encaixa no nosso workflow?

A maior parte dos fundadores pula essa etapa ou faz pela metade. Olha para dois concorrentes, acha um que odeia, e conclui que “nada serve.”

A versão honesta dessa pergunta é: gasta uma tarde de verdade mapeando o seu workflow como ele existe hoje, e leva esse mapa para três produtos reais e roda o workflow ali dentro. Não a demo. O workflow de verdade, com seus edge cases de verdade.

Você está procurando o gap entre o que o produto faz e o que você precisa. Um gap de 10% é aceitável; você aprende a conviver, e o produto provavelmente vai entregar os 10% que faltam em dois trimestres. Um gap de 40% é fatal. Você vai passar o próximo ano fazendo trabalho manual em torno das limitações, treinando gente em workarounds, e explicando para o time por que “a ferramenta funciona assim.”

A armadilha aqui é o gap da demo. Demos de vendas são afinadas para fazer o produto parecer que dá conta de todo caso. Não dão. O mapa do workflow é a única forma de ver onde o produto realmente quebra.

Se um produto encaixa com um gap tolerável: buy. Para a análise. Toca o barco. Não existe medalha por construir o que outra pessoa já construiu.

Se nenhum produto encaixa, vai para a pergunta três.

3. Dá pra chegar lá costurando o que já existe?

Essa é a pergunta que mais mudou desde 2022, porque a área de SaaS dobrou e a camada de integração amadureceu.

Costurar significa: pega dois ou três produtos que cada um cobre uma parte do seu workflow, conecta com automações, e adiciona a camada fina de lógica customizada que fecha a última milha. Um workflow stitched típico em early-stage hoje se parece com isto:

• HubSpot é dono do registro de contato.
• Um Typeform ou um formulário de intake customizado empurra novos leads para o HubSpot.
• Uma automação no n8n ou Make roteia leads de alto valor para um canal no Slack e um dashboard Retool.
• O dashboard Retool puxa o contato e mostra ao SDR uma visão custom, chama um par de APIs internas, e escreve de volta um status.

Isso é software stitched. Não é código sob medida puro, nem prateleira puro. É o padrão cavalo-de-batalha do stack moderno de early-stage.

Stitch ganha quando:

• O workflow é central, mas as peças já existem como produtos.
• A camada customizada que falta é rasa (um formulário, um dashboard, algumas automações).
• Você espera que o workflow mude todo trimestre pelo próximo ano. Camadas stitched são baratas de jogar fora. Código sob medida não é.

Stitch perde quando:

• A camada customizada cresceu para meia dúzia de automações, três Retool, e ninguém consegue descrever como aquilo funciona.
• Performance começa a importar (filas do n8n acumulando, rate limit do Zapier batendo, view de Airtable carregando devagar).
• Os próprios pontos de integração viram um peso de manutenção maior do que custaria ser dono do código.

Esse é o modo de falha que vale nomear explicitamente: a armadilha do stitch. Sistemas stitched são baratos de começar e caros de herdar. O fundador que montou sabe onde cada peça vive; o próximo funcionário abre o canvas do Make, vê quarenta e sete nodes conectando onze produtos, e pede demissão em menos de um mês. A gente já viu esse padrão vezes suficientes para tratar “temos um sistema stitched que ninguém mais consegue ler” como passivo ativo de contratação.

Se costurar funciona pelos próximos doze meses: stitch, e revisita nesse horizonte.

Se costurar já está quebrando, ou se o sistema atingiu o limite de complexidade, vai para a pergunta quatro.

4. O workflow está estável o suficiente para encodar?

O último portão é se o workflow parou de mudar toda semana.

Software sob medida é mais valioso quando você o escreve para um workflow que você entende. Se você ainda está iterando no que o workflow é (que passos existem, quem faz o quê, quais são os inputs), construir software para isso é um seguro caro contra a sua própria indecisão. Você vai construir a coisa errada, jogar fora, construir uma segunda versão, e descobrir que a terceira versão é a que você realmente queria. Esse é um custo real.

O sinal de que um workflow está estável o suficiente para encodar é operacional, não filosófico. Você consegue descrever o workflow para um novo funcionário em quinze minutos sem dizer “bom, depende.” As exceções têm regra. Os edge cases têm nome.

Se o workflow ainda está em fluxo: stitch por mais um trimestre. Não construa ainda.

Se o workflow está estável, as ferramentas existentes não encaixam, o gap é largo demais para costurar, e o workflow é central para receita: build.

Esse é o único caminho até o “build.” É mais estreito do que a maioria dos fundadores imagina.

Quanto “build” custa de verdade no estágio startup

A razão dessa decisão importar é a diferença de custo, e os números que a maioria dos fundadores cita para si mesmo estão errados por uma ordem de grandeza.

Para uma startup early-stage, construir software sob medida com um pequeno studio ou parceiro (não uma agência offshore genérica, não um time interno que você não tem ainda) tipicamente cai assim:

• Uma ferramenta interna pequena que substitui um workflow stitched: R$ 80K–R$ 250K, quatro a dez semanas. Um dashboard custom com algumas escritas no banco, uma integração externa, e uma UI limpa.
• Um v1 de uma superfície de produto central que clientes vão ver: R$ 350K–R$ 1,2M, três a seis meses. Frontend de verdade, usuários autenticados, modelo de dados pensado, um admin interno, pipeline de deploy.
• Um v1 de um workflow regulado (KYC, pagamentos, sinistros): R$ 700K–R$ 2,5M, seis a doze meses. Mesma coisa do item acima mais trilha de auditoria, fluxos de compliance, e a parte lenta de fazer segurança direito.

Esses são números de 2026 para um pequeno studio parceiro, trabalhando em TypeScript, React, Postgres, deployando para nuvem gerenciada. Os números sobem se o time é maior, descem se o time é mais afiado. Sobem mais rápido do que os fundadores esperam quando o escopo cresce sem ninguém chamar. A gente já escreveu mais sobre quanto custa de verdade desenvolver um app e sobre como a estrutura do contrato muda a matemática.

Os mesmos números em termos de SaaS: R$ 80K de desenvolvimento sob medida valem aproximadamente dois anos de uma ferramenta de R$ 500 por usuário para um time de dez. R$ 350K se aproxima de uma década do mesmo. Essa conta é o que deveria empurrar para o default buy.

A versão honesta de “quanto deveríamos gastar nisso”: se o workflow é central, a matemática fecha, e o gap é real, R$ 350K–R$ 1,2M para um v1 que é dono de um workflow que seus concorrentes não conseguem copiar em um trimestre não é caro. É o resto do espectro que enrasca o fundador.

Quando buy ganha (a resposta default)

Nas conversas que temos com fundadores, buy ganha oito em cada dez vezes. As razões são chatas e certas.

Ferramentas genéricas estão maduras. HubSpot, Notion, Linear, Stripe, Mercado Pago, Conta Azul, Pylon, Vanta: cada uma tem um time de produto de dezenas a centenas de pessoas, construindo exatamente a feature que você estaria construindo. Elas entregam mais rápido do que você. A postura de segurança é melhor do que a sua. As integrações são mais profundas. O preço, mesmo nos tiers mais altos, geralmente é menor do que o custo total de um engenheiro por um trimestre.

O erro do fundador é dar peso demais para os 10% específicos que a ferramenta não faz. Os 90% que ela faz são a vitória. A maioria dos workflows que você acha único não é. A gente consegue, em quinze minutos, dizer para um fundador se o workflow “custom” dele é realmente custom ou se é um workflow de prateleira que ele ainda não reconheceu. A Aggregation Theory do Ben Thompson é a leitura mais limpa sobre por que isso é estrutural, não acidental.

Se um produto cobre 70% ou mais do seu workflow real, buy. Conviva com o gap de 30%. Revisita daqui um ano.

Quando build ganha (as exceções estruturais)

Build ganha em um número pequeno de casos bem definidos.

O primeiro é superfície de produto. Se o software em questão é o que seus clientes efetivamente compram de você, construir não é opcional. Ninguém comprou uma assinatura SaaS de uma versão genérica do seu produto, porque ela não existe. Existe você. O software sob medida é a empresa.

O segundo é workflows operacionais que compõem vantagem. Alguns workflows não são o produto, mas geram vantagem mensurável em escala. Um motor de matching sob medida para um marketplace. Uma automação de sinistros para uma seguradora. Um sistema de conciliação para uma fintech. São workflows onde uma melhora de 10% em throughput se converte em mudança relevante de unit economics. Fornecedores de prateleira não conseguem afinar. Você consegue.

O terceiro é profundidade de integração. Se o workflow precisa ler e escrever em cinco sistemas internos com regras que são únicas do seu negócio, e o produto de prateleira ainda precisaria de um projeto de integração de seis meses para fazer metade do que você precisa, o custo de build converge com o custo de buy e a versão build é sua, sua para evoluir. A gente vê esse padrão com mais frequência em empresas late-seed e Série A que saíram de um setup stitched.

O quarto é responsabilidade regulatória. Quando você é a entidade responsável pela trilha de auditoria, pela criptografia, pela residência de dados, e pelo fluxo de consentimento, o custo de estar errado sobre a postura de compliance de um fornecedor às vezes é maior do que o custo de ser dono do código. Isso é mais comum em fintech, healthtech, e legaltech do que os fundadores imaginam.

Fora desses quatro casos, a resposta geralmente não é build.

A armadilha do stitch, e por que ela é o modo de falha de 2026

O debate de build vs buy de 2015 não é o debate de hoje. Em 2015, a escolha era real: existiam menos produtos SaaS, menos plataformas de integração, e a pergunta de escrever código tinha peso. Em 2026, quase todo workflow de early-stage pode ser costurado a partir de ferramentas existentes, e a pergunta mudou.

O novo modo de falha é o sistema stitched que ninguém consegue ler. Um fundador compra oito ferramentas, contrata um operacional part-time para conectar com Zapier, coloca por cima dois dashboards no Retool, e dezoito meses depois descobre que ninguém no time entende como o workflow de onboarding de cliente funciona. Não tem documentação. O fluxograma na cabeça dele é o único fluxograma. Quando o operacional sai, o sistema vira um ponto único de falha que ninguém ousa tocar.

Hoje a gente avisa fundadores ativamente contra isso. Três sinais:

• Seu sistema stitched tem mais de dez pontos de integração, e o mapa de dependências existe só na cabeça de alguém.
• Mais de um workflow crítico fica em silêncio por um dia porque uma automação Make bateu rate limit e ninguém notou.
• A contratação demora mais porque novos funcionários não conseguem ser onboardados na sua stack sem um tour da pessoa que montou.

Quando algum desses sinais está aceso, a resposta correta geralmente não é “construir tudo.” É “encodar a espinha do workflow em código e manter as folhas como SaaS.” Um pequeno software house consegue fazer isso em uma engagement de seis a dez semanas. O resultado é um sistema que o time consegue ler, que sobrevive a turnover, e que mantém os investimentos em SaaS vivos nas partes do workflow onde ainda fazem sentido.

O que fazer essa semana

Se você está olhando para essa decisão hoje, o trabalho não é filosófico. É uma tarde.

Escreve o workflow. Lista as ferramentas que tocam nele. Roda as quatro perguntas, na ordem. Se o workflow não é central, para e compra alguma coisa. Se um produto encaixa, para e compra. Se uma camada stitched funciona pelos próximos doze meses, para e costura, e marca um lembrete no calendário para revisitar. Se nada disso vale e o workflow é estável, build.

Os fundadores que acertam essa decisão não são os que agonizam em cima dela. São os que formulam a pergunta certa, decidem rápido, e revisitam a decisão quando o negócio muda. É aí que está a maior parte do valor.

FAQ

Qual a diferença entre build e buy?
Build significa escrever um software sob medida para o seu workflow específico. Buy significa comprar um produto pronto que resolve um problema parecido para muitas empresas. Na prática existe uma terceira opção, costurar múltiplos produtos SaaS com automações e uma fina camada custom, e ela é a resposta certa com mais frequência do que os fundadores percebem em estágios iniciais.

É melhor construir ou comprar?
Para um fundador não-técnico early-stage, buy é a resposta certa na maior parte das vezes. Build só é a resposta certa quando o workflow é central para receita, nenhum produto de prateleira encaixa, costurar não é viável, e o workflow está estável o suficiente para encodar. Fora dessas condições, software sob medida é mais caro e mais lento do que as alternativas.

Quanto custa build vs buy?
Uma ferramenta interna sob medida pequena tipicamente custa R$ 80K–R$ 250K e roda de quatro a dez semanas com um pequeno studio parceiro. Um v1 de uma superfície de produto voltada para o cliente cai em R$ 350K–R$ 1,2M. O gasto equivalente em SaaS para o mesmo workflow geralmente é R$ 20K–R$ 150K por ano. A matemática favorece buy, a não ser que o workflow seja central e duradouro.

Quando uma startup deve construir o próprio software?
Quando o software É o produto, quando um workflow operacional gera vantagem composta em escala, quando a profundidade da integração entre sistemas internos é única do negócio, ou quando a responsabilidade regulatória torna o risco de fornecedor inaceitável. Esses são os quatro casos em que build ganha. Fora deles, buy ou stitch.