Um cliente me ligou em 2021 — puro pânico na voz. Ele tinha gasto £140.000 em quatorze meses desenvolvendo uma plataforma de faturamento customizada. Seu time de dev tinha entregado talvez 60% da especificação. E em algum lugar perto do mês onze, ele descobriu que Invoice Ninja existia, era open-source, e fazia 90% do que ele precisava fora da caixa. De graça.Invoice Ninjaexisted, was open-source, and did 90% of what he needed out of the box. For free.
Aquela ligação me assombra um pouco. Porque a resposta honesta é: eu também cometi o erro oposto. Seahawk teve um projeto em 2019 onde gastamos oito meses costurando juntos cinco ferramentas SaaS diferentes — Airtable, Zapier, Typeform, HubSpot, e um CMS Webflow customizado — para gerenciar um fluxo de trabalho do cliente que, em retrospecto, um desenvolvimento customizado de £15.000 teria resolvido limpo e permanentemente. Estávamos pagando aproximadamente £900/mês em assinaturas combinadas no final. Faça as contas ao longo de três anos.
Nenhum extremo é automaticamente certo. E qualquer um vendendo uma regra simples — "sempre construa", "nunca construa" — está vendendo algo. Então aqui está o framework real 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 mora a diferenciação no meu produto? Se a coisa que você está considerando construir é essencial para sua vantagem competitiva — a razão pela qual clientes escolhem você em vez da próxima aba do navegador — então construir provavelmente faz sentido. Se é infraestrutura, administração ou funcionalidade de commodity, comprar é quase certamente mais barato em termos reais.reasoncustomers will choose you over the next tab in their browser — then building probably makes sense. If it's infrastructure, admin, or commodity functionality, buying is almost certainly cheaper in real terms.
Eu faço aos fundadores uma pergunta primeiro: Seus usuários vão ver essa coisa? Se a resposta é sim e molda a experiência deles de forma significativa, pode valer a pena construir. Se é back-office, operacional ou interno, o critério para construir deve ser muito alto.Will your users ever see this thing?If the answer is yes and it shapes their experience in a meaningful way, it might be worth building. If it's back-office, operational, or internal, the bar for building should be very high.
---
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 é uma coisa única. Você está na responsabilidade para sempre, a menos que você descontinue a coisa.Not a one-off. You're on the hook forever unless you sunset the thing.
- Patches de segurança. Um vendor SaaS faz isso para você. Você constrói, você possui, incluindo os alerts das 2 da manhã.A SaaS vendor handles this for you. You build it, you own it, including the 2am alerts.
- Onboarding de novos devs. Se seu engenheiro líder sair, a próxima pessoa precisa aprender seu codebase. Isso é semanas de tempo faturável.If your lead engineer leaves, the next person needs to learn your codebase. That's weeks of billable time.
- Expansão de escopo. Stakeholders veem uma ferramenta customizada e assumem que ela consegue fazer tudo. O escopo cresce. Os custos vêm atrás.Stakeholders see a custom tool and assume it can do everything. Scope expands. Costs follow.
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 há 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 fracassando completamente. Isso não é uma razão para nunca construir — é uma razão para entrar com os olhos bem abertos.Standish Group's CHAOS Reporthas been showing for decades that software projects overrun their budgets at an alarming rate. The number sits around 45-50% of projects being "challenged" or outright failing. That's not a reason to never build — it's a reason to go in clear-eyed.
---
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 começo do ano tem o hábito engraçado de virar £490/mês até o terceiro ano — uma vez que você está em um tier mais alto, você adicionou seats, e o vendor fez uma "reestruturação de preços" (leia-se: aumento). Eu vi isso acontecer com clientes em Salesforce, Intercom e Mixpanel. Não é malicioso. É só como a economia de SaaS funciona.
As três armadilhas de SaaS nas quais fundadores caem
- Vendor lock-in. 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 um trabalho significativo de engenharia de dados.Your data is in their format, their schema, their export flow. Leaving is painful and sometimes effectively impossible without significant data engineering work.
- Complexidade de Franken-stack. Cinco ferramentas que se integram meio-a-meio via Zapier não é um sistema. É um passivo. Uma deprecação de API e as coisas começam a desmoronar.Five tools that sort-of integrate via Zapier is not a system. It's a liability. One API deprecation and things start falling apart.
- Crescimento de assinaturas. Ninguém faz auditoria da sua stack 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 apenas um recurso cada.Nobody audits their tool stack annually. They should. I ran an audit for a 12-person agency last year and found £3,200/month in SaaS they'd either stopped using or were using for one feature each.
Dito isto — para funções commodity, SaaS é quase sempre a escolha certa. Entrega de email? Postmark ou SendGrid. Pagamentos? Stripe, obviamente. Autenticação? Auth0 ou Clerk. Ninguém deveria estar construindo seu próprio processador de pagamentos em 2024.Postmarkor SendGrid. Payments? Stripe, obviously. Auth? Auth0 or Clerk. Nobody should be building their own payment processor in 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 é o que torna seu produto genuinamente diferente — construir merece uma 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.Product Huntand G2 are genuinely useful here — not as gospel but as a starting inventory.
Pergunta 3: Qual é seu tempo realista para gerar valor?
Uma ferramenta SaaS pode estar ativa hoje. Uma construção customizada leva semanas no mínimo, geralmente meses. Se velocidade importa — e em empresas em estágio inicial quase sempre importa — comprar te compra tempo para aprender o que você realmente precisa antes de se comprometer a construir.
Lá em 2022, a Seahawk trabalhou com uma startup de logística que queria um dashboard customizado de otimização de rotas. A gente os convenceu a usar primeiro uma camada de API white-labelled (eles usaram Route4Me como ponto de partida). Seis meses depois, eles sabiam exatamente quais três features seus clientes realmente se importavam. A construção customizada que eventualmente eles contrataram tinha metade do escopo — e era duas vezes melhor — porque eles tinham aprendido em produção em vez de em um documento de spec.Route4Meas a starting point). Six months later, they knew exactly which three features their customers actually cared about. The custom build they eventually commissioned was half the scope — and twice as good — because they'd learned in production rather than in a spec document.
Pergunta 4: O que acontece quando isso quebra?
Porque vai quebrar. A questão é quem conserta e com que velocidade. 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 retido, você está em apuros. Isso não é hipotético — já vi founders presos com software customizado quebrado por semanas porque seu 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.
- Seu IP central é o software em si. Se você está vendendo um produto SaaS, você não pode terceirizar a coisa que você está vendendo.If you're selling a SaaS product, you can't outsource the thing you're selling.
- Requisitos regulatórios significam que pronto para usar não vai funcionar. Certas aplicações de fintech, healthcare e legal têm constraints de compliance que a maioria das ferramentas SaaS não foi construída para satisfazer.Certain fintech, healthcare, and legal applications have compliance constraints that most SaaS tools aren't built to satisfy.
- Você já validou com uma ferramenta SaaS e sabe exatamente o que precisa. Esta é a melhor posição possível antes de encomendar um desenvolvimento customizado.This is the best possible position to be in before commissioning a custom build.
- O preço do SaaS em escala é genuinamente mais caro do que ter propriedade. Faça as contas com seu uso projetado para o Ano 3. Às vezes, o custom vence em pura economia.Do the maths at your projected Year 3 usage. Sometimes custom wins on pure economics.
---
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 funcionalidade é 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á desenvolvendo como founder para evitar tomar uma decisão de negócio mais difícil, isso vale a pena examinar. Desenvolvimentos customizados podem ser uma forma muito cara de procrastinação.to avoid making a harder business decision, that's worth examining. Custom builds can be a very expensive form of procrastination.
---
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 os componentes commodity agressivamente e construa a camada fina de lógica diferenciada por cima. Seu CRM é HubSpot. Sua central de suporte é Intercom. Mas o engine de fluxo de trabalho sob medida que os conecta e automatiza seu processo específico? 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 cuida dos 80%. Nós construímos os 20% que importam. É um conselho chato. Também é o conselho que funcionou mais frequentemente.
---
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 — quero dizer quatro ou cinco horas, não vinte minutos — mapeando cada produto SaaS em sua categoria. Se você fez isso e nada cobre seu requisito principal, pergunte-se se esse requisito é realmente necessário agora ou se é um nice-to-have que você elevou a bloqueador. Se é realmente necessário e realmente não atendido, esse é um sinal que vale a pena levar a sério.necessary right nowor whether it's a nice-to-have you've elevated into a blocker. If it's truly necessary and truly unserved, that's a signal worth taking seriously.
Qual é a equipe mínima que você precisa para possuir responsavelmente software customizado?
No mínimo: um desenvolvedor que entenda profundamente o codebase, e ou um segundo desenvolvedor ou uma agência retida que possa cobrir quando ele estiver indisponível. Possuir software customizado com um único freelancer e sem backup é uma posição frágil. Já vi isso causar danos operacionais reais quando essa pessoa se torna 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 um custo inicial de construção significativamente menor. O porém: você ainda está possuindo a infraestrutura e ainda precisa de alguém técnico para gerenciá-la. Não é gratuito — é apenas mais barato começar.Metabasefor analytics, Directus for headless CMS, or ERPNext for operations give you the flexibility of custom software with significantly lower initial build cost. The catch: you're still owning infrastructure and you still need someone technical to manage it. It's not free — it's just cheaper to start.
---
Um Pensamento Final
A questão construir vs comprar não tem uma resposta. Tem a sua resposta, específica ao seu estágio, seu time, sua posição competitiva, e o que você realmente validou até agora.youranswer, specific to your stage, your team, your competitive position, and what you've actually validated so far.
No 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 uma stack SaaS bem configurada. O fundador de faturamento que mencionei no início? Ele eventualmente construiu algo genuinamente customizado — mas apenas depois que dezoito meses usando Invoice Ninja o ensinaram exatamente o que seus clientes realmente precisavam. A construção foi melhor pela espera.
Comece com a opção entediante. Ganhe o direito de construir algo novo.