Um cliente me ligou em 2021, puro pânico na voz. Ele havia gasto £140.000 em catorze meses construindo uma plataforma de faturamento customizada. Seu time de dev tinha entregue talvez 60% da spec. E em algum momento do mês onze, ele descobriu que Invoice Ninja existia, era open-source, e fazia 90% do que ele precisava pronto para usar. De graça.
Aprendizado-chave: Compre SaaS até que o imposto de assinatura, propriedade dos dados, ou desajuste de workflow realmente morda; construa customizado quando a ferramenta é o núcleo de como o negócio vence.
Aquele telefonema me assombra um pouco. Porque a resposta honesta é: eu cometi o erro oposto também. Seahawk teve um projeto em 2019 onde passamos oito meses costurando cinco ferramentas SaaS diferentes, Airtable, Zapier, Typeform, HubSpot, e um CMS customizado em Webflow, para gerenciar um fluxo de cliente que, em retrospectiva, uma construção customizada de £15.000 teria resolvido de forma limpa e permanente. Estávamos pagando aproximadamente £900/mês em assinaturas combinadas no final. Faça as contas em três anos.
Nenhum extremo é automaticamente certo. E qualquer um vendendo uma regra limpa pra você, "sempre construir", "nunca construir", está vendendo algo. Então aqui está o framework atual que uso quando um fundador se senta comigo e faz a pergunta.
---
Primeiro, Admita o Que Você Está Realmente Decidindo
Isso não é uma decisão técnica. Não é mesmo. É uma decisão de negócio disfarçada de técnica.
Quando você diz "devo construir ou comprar?", o que você está realmente perguntando é: onde vive a diferenciação no meu produto? Se a coisa que você está considerando construir é central para sua vantagem competitiva, a razão pela qual clientes vão te escolher em vez da próxima aba no navegador, então construir provavelmente faz sentido. Se é infraestrutura, admin, ou funcionalidade commodity, comprar é quase certamente mais barato em termos reais.
Faço uma pergunta aos fundadores primeiro: Seus usuários vão ver essa coisa? Se a resposta é sim e ela molda a experiência deles de forma significativa, pode valer a pena construir. Se é back-office, operacional, ou interno, a barra para construir deveria ser muito alta.
---
O Custo Real de Construir (As Pessoas Subestimam Isso Muito)
Vou ser direto. Desenvolvimento customizado custa mais do que você pensa, leva mais tempo do que você é informado, e requer manutenção contínua que ninguém orça.
O que fundadores realmente esquecem de precificar
- Manutenção e hosting. Não é um pagamento único. Você fica preso para sempre a menos que você descontinue a coisa.
- Patches de segurança. Um vendor SaaS cuida disso para você. Você constrói, você é dono, incluindo os alertas das 2 da manhã.
- Onboarding de novos devs. Se seu lead engineer sair, a próxima pessoa precisa aprender seu codebase. Isso são semanas de tempo billable.
- Feature creep. Stakeholders veem uma ferramenta customizada e assumem que ela pode fazer tudo. O escopo expande. Os custos seguem.
Uma regra grosseira que uso: pegue sua estimativa inicial de dev, multiplique por 1.6 para entrega realista, depois adicione 20% desse número anualmente para manutenção. Se esses números ainda fazem sentido para o negócio, ótimo. Se não fazem, você tem sua resposta.
Honestamente, o CHAOS Report do Standish Group vem mostrando por décadas que projetos de software extrapolam seus orçamentos em uma taxa alarmante. O número fica em torno de 45-50% dos projetos sendo "desafiadores" ou francamente falhando. Isso não é uma razão para nunca construir, é uma razão para entrar de olhos abertos.
---
O Custo Real do SaaS (Também Subestimado, Só que de Forma Diferente)
SaaS parece barato até não parecer mais.
O plano de £49/mês que parecia razoável no início do ano tem um hábito engraçado de virar £490/mês até o ano três, uma vez que você está em um tier mais alto, adicionou assentos, e o vendor fez uma "reestruturação de preços" (leia-se: aumento). Vi isso acontecer com clientes em Salesforce, Intercom, e Mixpanel. Não é malicioso. É só como a economia SaaS funciona.
As três armadilhas de SaaS nas quais fundadores caem
- Dependência do fornecedor. Seus dados estão no formato deles, no schema deles, no fluxo de exportação deles. Sair é doloroso e às vezes efetivamente impossível sem trabalho significativo de engenharia de dados.
- Complexidade de Franken-stack. Cinco ferramentas que se integram meio que via Zapier não é um sistema. É uma responsabilidade. Uma deprecação de API e as coisas começam a desmoronar.
- Crescimento de assinatura. Ninguém audita sua pilha de ferramentas anualmente. Deveriam. Fiz uma auditoria para uma agência de 12 pessoas no ano passado e encontrei £3.200/mês em SaaS que eles tinham parado de usar ou estavam usando por um recurso cada.
Dito isso, para funções commodity, SaaS é quase sempre a escolha certa. Entrega de email? Postmark ou SendGrid. Pagamentos? Stripe, obviamente. Auth? Auth0 ou Clerk. Ninguém deveria estar construindo seu próprio processador de pagamento em 2024.
---
Um Framework Que Funciona de Verdade
Certo. Aqui está como eu penso sobre isso. Quatro perguntas, em ordem.
Pergunta 1: Isso é um diferencial competitivo?
Se sim, se isso é a coisa que torna seu produto genuinamente diferente, construir é digno de consideração séria. Se não, pare aqui. Compre.
Pergunta 2: Existe uma boa alternativa SaaS?
Boa o suficiente, não perfeita. Fundadores rotineiramente constroem porque "nada por aí faz exatamente o que precisamos." Às vezes é verdade. Frequentemente significa que eles não procuraram bem o suficiente, ou estão confundindo "precisamos configurar isso bem" com "precisamos construir algo novo."
Gasto pelo menos duas horas pesquisando o mercado de SaaS antes de recomendar uma construção customizada. Product Hunt e G2 são genuinamente úteis aqui, não como evangelho mas como um inventário inicial.
Pergunta 3: Qual é seu tempo realista para gerar valor?
Uma ferramenta SaaS pode estar rodando hoje. Um desenvolvimento customizado leva semanas no mínimo, geralmente meses. Se velocidade importa, e em startups em estágio inicial quase sempre importa, comprar uma solução pronta te compra tempo para aprender o que você realmente precisa antes de se comprometer a construir.
Lá em 2022, Seahawk trabalhou com uma startup de logística que queria um dashboard customizado de otimização de rotas. A gente os convenceu a usar uma camada de API white-labelled primeiro (eles usaram Route4Me como ponto de partida). Seis meses depois, eles sabiam exatamente quais três features os clientes deles realmente se importavam. O desenvolvimento customizado que eles eventualmente contrataram tinha metade do escopo e era duas vezes melhor, porque eles tinham aprendido em produção em vez de em um documento de especificação.
Pergunta 4: O que acontece quando isso quebra?
Porque vai quebrar. A questão é quem conserta e com que rapidez. Com SaaS, você abre um ticket de suporte e reclama no Twitter. Com software customizado, você liga para seu time de dev. Se você não tem um time de dev contratado, você está em apuros. Não é hipotético, já vi founders presos com software customizado quebrado por semanas porque o desenvolvedor freelancer saiu de férias.
---
Quando Construir É Claramente a Decisão Certa
Existem situações em que customizado é obviamente correto. Deixa eu nomear elas claramente.
- Sua IP principal é o próprio software. Se você está vendendo um produto SaaS, você não pode terceirizar a coisa que está vendendo.
- Requisitos regulatórios significam que soluções prontas não vão funcionar. Certas aplicações de fintech, healthcare e legal têm restrições de compliance que a maioria das ferramentas SaaS não foi construída para satisfazer.
- Você já validou com uma ferramenta SaaS e sabe exatamente o que precisa. Esta é a melhor posição possível antes de contratar uma construção customizada.
- O preço de SaaS em escala é genuinamente mais caro que propriedade. Faça as contas na sua projeção de uso do Ano 3. Às vezes custom vence por pura economia.
---
Quando Comprar É Claramente a Decisão Certa
Da mesma forma, algumas situações tornam a compra óbvia:
- Você está pré-receita ou pré-product-market fit. Ponto final.
- A função é infraestrutura commodity: email, pagamentos, autenticação, armazenamento, análise.
- Você precisa que funcione neste trimestre, não neste ano.
- Seu time não tem capacidade de engenharia interna e você não pode se dar ao luxo de contratar adequadamente.
Eu também acrescentaria: se você está construindo como founder para evitar tomar uma decisão de negócio mais difícil, vale a pena examinar isso. Construções customizadas podem ser uma forma muito cara de procrastinação.
---
O Caminho Híbrido (Frequentemente a Jogada Mais Inteligente)
Aqui está a coisa que ninguém fala o suficiente: construir e comprar não são mutuamente exclusivos.
A abordagem mais pragmática que vi funcionar repetidamente é esta: compre as peças commodity agressivamente e construa uma fina camada de lógica diferenciada por cima. Seu CRM é HubSpot. Sua central de suporte é Intercom. Mas o mecanismo de workflow customizado que conecta os dois e automatiza seu processo específico? Isso são duas semanas de desenvolvimento customizado, não seis meses.
Na Seahawk, construímos centenas de sites em WordPress, uma plataforma comprada, com plugins customizados que fazem coisas genuinamente inovadoras. A plataforma lida com os 80%. A gente constrói os 20% que importam. É conselho chato. Também é o conselho que mais funcionou.
---
FAQ
Como sei se meu caso de uso é realmente único o suficiente para justificar uma construção customizada?
Resposta honesta: a maioria não é. Comece passando uma tarde séria, falo de quatro ou cinco horas, não vinte minutos, mapeando cada produto SaaS na sua categoria. Se você fez isso e nada cobre seu requisito core, pergunte a si mesmo se esse requisito é realmente necessário agora ou se é um nice-to-have que você elevou a um blocker. Se é verdadeiramente necessário e verdadeiramente desatendido, esse é um sinal que merece ser levado a sério.
Qual é a equipe mínima que você precisa para possuir responsavelmente software customizado?
No mínimo: um desenvolvedor que entenda o codebase profundamente, e ou um segundo desenvolvedor ou uma agência retida que possa cobrir quando ele não estiver disponível. Deter software customizado com um freelancer único e sem backup é uma posição frágil. Já vi isso causar dano operacional real quando essa pessoa fica indisponível, férias, doença, uma proposta de emprego melhor.
Devo construir internamente ou contratar uma agência para construir algo customizado?
Depende quase inteiramente de se o software é seu negócio principal. Se você é uma empresa de software, quase certamente quer ter desenvolvimento interno eventualmente, mesmo que use uma agência para começar. Se software é uma ferramenta que suporta seu negócio em vez de ser o negócio em si, uma relação de agência com um SLA apropriado geralmente é mais custo-efetiva do que contratar engenheiros em tempo integral.
Open-source é um caminho do meio entre construir e comprar?
Sim, e é subutilizado. Ferramentas como Metabase para analytics, Directus para headless CMS, ou ERPNext para operações te dão a flexibilidade de software customizado com custo inicial significativamente menor. A pegadinha: você ainda está detendo infraestrutura e ainda precisa de alguém técnico para gerenciar. Não é grátis, é só mais barato para começar.
---
Um Pensamento Final
A pergunta build vs buy não tem uma resposta. Tem sua resposta, específica ao seu estágio, seu time, sua posição competitiva, e o que você realmente validou até agora.
O que eu questionaria é o romantismo em torno de construir. Software customizado não é inerentemente mais sério, mais escalável ou mais impressionante do que um SaaS stack bem configurado. O founder de faturamento que mencionei no início? Ele eventualmente construiu algo genuinamente customizado, mas só depois de dezoito meses usando Invoice Ninja que o ensinou exatamente o que seus clientes realmente precisavam. O desenvolvimento foi melhor pela espera.
Comece com a opção entediante. Ganhe o direito de construir algo novo.
Leitura relacionada: Building a Real-Time Auction Site with Next.js & Supabase, desenvolvimento web personalizado, e Next.js.