Todo time técnico, uma hora, olha para a plataforma de ecommerce e pensa a mesma coisa: "isso aqui a gente construía melhor". O gatilho varia — a mensalidade que sobe, o percentual sobre GMV que incomoda, uma limitação que trava um projeto, ou só o desconforto de depender de um fornecedor. E a conclusão parece óbvia para quem sabe programar: se a gente consegue construir, por que pagar?

Porque "conseguimos construir" responde à pergunta errada. Engenheiro bom constrói qualquer coisa — isso nunca esteve em dúvida. A dúvida é o que você assina junto. Quando você compra uma plataforma, paga uma conta. Quando você constrói, herda um sistema para manter para sempre. E é aí que o orçamento estoura: não na construção, que você estima, mas na manutenção, que você ignora. É a mesma lógica do custo total de propriedade (TCO) — o preço de entrada é a menor parte da conta.

Deixo uma carta na mesa antes de seguir: em toda a minha carreira, nenhuma plataforma de ecommerce que operei custou menos de R$ 1 milhão por ano — somando licença, integração, ferramentas em volta e as horas do time que mantém tudo de pé. É esse o tamanho real da conta que você decide comprar ou construir; quem imagina construir a própria por muito menos quase sempre esqueceu alguma linha.

Construir se estima; manter é o que estoura o orçamento

A construção é um projeto: tem escopo, prazo e fim. A manutenção não tem fim. E é ela que domina o custo de um software ao longo da vida — em média 60%, mais em quem lida com pagamento e fisco.

A diferença decisiva é quem paga essa conta de manutenção. Uma plataforma comprada dilui o custo de manter entre milhares de lojistas: quando o navegador muda, quando surge um método de pagamento, quando uma falha de segurança aparece, o fornecedor corrige uma vez e todo mundo recebe. Quem constrói dilui esse custo entre um lojista — você. Patch de segurança, atualização de dependência, PCI, plantão para o site não cair na Black Friday, o caso de borda que só aparece no pedido de número 40 mil: tudo isso é seu, sozinho, todo mês.

E há uma linha da conta que não é trabalho, é risco: o vazamento de dados. Ao comprar a plataforma, você transfere boa parte desse risco ao fornecedor — a segurança da infraestrutura, a certificação PCI-DSS dos dados de cartão, o time que responde a incidente às três da manhã. Na prática, a plataforma "compra" para você o risco jurídico de um vazamento. Ao construir, esse risco passa a ser inteiro seu: um incidente no seu sistema é a sua responsabilidade perante a LGPD, com multa de até 2% do faturamento (limitada a R$ 50 milhões por infração) aplicada pela ANPD — sem contar o dano de imagem. Segurança de dados não é custo de manutenção; é uma apólice que você passa a emitir sozinho.

O protótipo engana. "Um checkout" sai em um sprint. O checkout que aguenta PIX, parcelado, antifraude, 3DS, conciliação, estorno e não cai no pico leva anos — e nunca fica pronto de verdade.

Software que você constrói não é um ativo que você tem. É um passivo que você mantém.

O custo que não entra na planilha: seus melhores engenheiros

Suponha que a conta de dinheiro empatasse. Ainda sobraria o custo mais caro de construir, e o que ninguém coloca na planilha: o que os seus melhores engenheiros deixam de fazer.

Todo desenvolvedor sênior mantendo um carrinho, um catálogo ou um checkout feitos em casa é um sênior que não está construindo aquilo que diferencia a sua operação. O recurso escasso de verdade não é dinheiro — é atenção de engenharia. Gastá-la reinventando uma peça que mil fornecedores já resolveram é o oposto de vantagem competitiva: é pagar caro para ficar igual a todo mundo, com atraso.

A pergunta não é "conseguimos construir?". É "este é o melhor uso do recurso mais escasso que temos?".

A esteira de compliance brasileira não para nunca

É no Brasil que construir dói mais. Nota fiscal eletrônica, SPED, ICMS, PIX, parcelamento sem juros, antifraude, LGPD — e agora a reforma tributária. Nada disso é "faz uma vez"; é uma esteira que anda sozinha, e quem construiu corre atrás dela para sempre.

O exemplo está acontecendo agora. Em 2026 começou a fase de teste do novo modelo tributário: a partir de 3 de agosto de 2026, documento fiscal eletrônico emitido sem os campos de IBS e CBS simplesmente não passa — e a transição vai até 2033, mudando as regras a cada ano. Uma plataforma comprada te entrega essa atualização pronta, no prazo. Uma plataforma construída significa o seu time parando o roadmap para implementar mudança tributária sob prazo legal — de novo, e de novo, por sete anos.

▲Você não comprou uma plataforma; adotou uma esteira

Construir a plataforma não é adquirir um ativo estável — é assinar um contrato de manutenção perpétua com o fisco, as bandeiras e os navegadores. A conta de construir some perto da conta de acompanhar um ambiente que muda sem pedir licença.

A pergunta certa: o que é commodity e o que é o seu diferencial

"Buy ou build" como escolha binária para a plataforma inteira é a pergunta errada. A boa pergunta se faz capacidade por capacidade: isto é commodity ou é o meu diferencial?

Carrinho, catálogo, motor de promoção, CMS, busca, checkout, gateway: commodity. São problemas resolvidos, e resolvidos melhor do que você resolveria sozinho — porque o fornecedor os aperfeiçoa com o aprendizado de milhares de lojas, não de uma. Já a regra de precificação B2B que só a sua empresa tem, a otimização logística proprietária, a experiência que é a cara da sua marca: aí talvez valha construir — mas como uma camada fina sobre uma fundação comprada, não recriando a fundação.

◎A regra

Compre o que te iguala; construa só o que te diferencia. Se o cliente nunca vai perceber a diferença, é commodity — não construa. Se aquilo é o motivo de ele comprar de você, é candidato a construir.

O meio-termo que quase sempre é a resposta: headless / composable

Entre "compro tudo fechado" e "construo tudo do zero" existe o caminho que mais faz sentido para quem cresceu: headless / composable. Você compõe motores comprados — pagamento, busca, checkout, CMS — e constrói por cima só a vitrine e a lógica de negócio que te diferencia.

É honesto reconhecer o custo: ir headless reintroduz uma conta de frontend e de hospedagem que o SaaS fechado embutia (como notei no artigo de TCO). Você troca conveniência por controle, e controle vem com responsabilidade. Mas é aqui que o "buy vs build" deixa de ser uma briga religiosa e vira uma decisão de arquitetura: comprado o motor, construída a experiência.

Quando construir realmente vale

Existe, sim, a hora de construir. Ela é mais rara do que a vontade sugere, e costuma ser óbvia para quem está nela:

  • Escala extrema. Quando a fatia sobre o GMV vira uma fortuna anual — bem maior do que o custo de sustentar um time de plataforma de verdade (segurança, pagamentos, compliance, plantão). Como ordem de grandeza: essa conta raramente vira a favor do build antes de algumas centenas de milhões de reais de GMV por ano — é o patamar em que ~1% de GMV pago à plataforma passa a superar, com folga, a folha de um time sênior dedicado. O número exato depende do seu take rate e da sua complexidade, mas abaixo dessa casa a conta quase nunca fecha. E quem está de fato acima dela já sabe — não está lendo isto para decidir.
  • Modelo que nenhuma plataforma suporta. Um marketplace atípico, um B2B com regras profundas, uma vertical regulada onde o produto pronto simplesmente não cabe. O sinal é o volume: as integrações e personalizações que a sua operação exige são incontáveis e não estão disponíveis nem minimamente em plataforma alguma. Quando comprar significaria reconstruir quase tudo por cima de um produto que resiste a cada ajuste, construir a base certa desde o início sai mais barato — e mais estável.
  • A plataforma É o diferencial. Se o jeito como você vende é o próprio produto, terceirizá-lo é terceirizar a vantagem.

E o anti-padrão que junta o pior dos dois lados: customizar pesado por cima de um SaaS que não foi feito para aquilo. Você paga a licença e a engenharia, e cada atualização da plataforma quebra as suas adaptações. É a dívida de customização — e ela cresce sozinha. Se você está reescrevendo metade do SaaS, ou escolheu o SaaS errado, ou já era caso de ir headless.

Uma opinião pessoal: quando o build deixa de ser um site

As seções acima são a resposta técnica — fria, de planilha. Esta é pessoal: uma estratégia, não apenas um cálculo. Porque existe um caso de construir que me anima de verdade, e ele não cabe bem em uma conta de TCO.

É quando a ambição não é ter um site, mas erguer a plataforma de operação da empresa inteira. Um sistema único que orquestra todos os pontos onde a marca vende e opera — o online, as lojas físicas, os franqueados, os marketplaces — sob a mesma lógica, o mesmo dado e o mesmo padrão. E que, por cima disso, automatiza: o marketing (campanha, régua, recomendação), a inteligência comercial (precificação, elasticidade de preço e de frete, sortimento, previsão de demanda) e boa parte da operação (estoque, reposição, roteirização).

Pense no que isso captura. Quanto você ganha podendo subir o preço automaticamente conforme o estoque de um item vai se esgotando? Quanto deixa de perder quando a campanha no Google Ads se interrompe sozinha no minuto em que aquele produto acaba — em vez de seguir pagando por clique que cai em uma página de "esgotado"? Esse dinheiro só aparece quando estoque, preço e mídia falam a mesma língua, no mesmo sistema e em tempo real. Em uma pilha de ferramentas soltas, cada uma de um fornecedor, essa conversa raramente acontece sozinha — e o ganho fica na mesa.

Aqui o software deixa de ser encanamento comprável e vira o modelo operacional do negócio — o jeito como a empresa funciona, codificado. Nesse território a lógica de "compre a commodity" não morre, só muda de lugar: você ainda compõe motores comprados por baixo (pagamento, busca, ERP), mas a camada que unifica e automatiza tudo é sua — porque não existe produto de prateleira que junte a sua operação, com os seus canais e as suas regras, do jeito que só faz sentido para você. Um franqueador cujo diferencial é a consistência operacional entre unidades está construindo exatamente isso; terceirizá-lo seria terceirizar a própria vantagem.

Sou honesto: é o caminho mais caro, mais lento e mais fácil de subestimar de todos — vale tudo o que este artigo disse sobre manutenção, compliance e custo de oportunidade, elevado ao quadrado. Mas é também o único em que "construir" deixa de ser uma economia mal calculada e vira uma aposta estratégica de verdade. Quando a plataforma é a forma de a empresa operar, construí-la é construir a empresa. Essa foi a fórmula que apliquei em empresas como a MadeiraMadeira e a ABC da Construção para virarem unicórnios.

Como decidir

Antes de aprovar qualquer "vamos construir", passe por estas seis perguntas:

  1. Isto é o nosso diferencial ou é encanamento que o cliente nunca vai ver?
  2. Qual o TCO de 3 anos do run (manter), não só do build (construir)?
  3. Quem mantém quando o engenheiro que construiu sair? (o fator ônibus do código feito em casa)
  4. Qual o custo de oportunidade — o que esse time deixaria de fazer para manter isto?
  5. Dá para comprar 80% e construir os 20% que importam?
  6. É reversível? Comprado, você migra (dói, mas dá); construído, você se casa com a manutenção.

Construir a própria plataforma é a decisão mais fácil de justificar tecnicamente e a mais difícil de justificar no resultado. Na dúvida, compre a fundação, construa o diferencial — e reserve os seus melhores engenheiros para aquilo que só a sua empresa pode fazer.

Ferramenta · Lojistas

Calculadora de custo de stack

Quanto sua loja gasta de verdade em plataforma, apps e taxas — e como isso se compara.

→

Comece medindo o lado "buy": quanto a sua stack comprada custa de verdade, somando plataforma, apps, ferramentas e taxas. Depois some o que o "build" acrescenta — as horas de manutenção que não aparecem em tabela de preço nenhuma. Para pontos de partida por plataforma, veja os comparativos de VTEX vs Shopify e Nuvemshop vs Tray, e o resto do pilar em Plataformas & Stack.

Referências