Um cliente me ligou em 2021 -- puro pânico na voz dele. Ele tinha gasto £140.000 em quatorze meses construindo uma plataforma de faturamento customizada. Seu time de dev tinha entregue talvez 60% da spec. E em algum ponto do mês onze, ele descobriu que Invoice Ninja existia, era open-source, e fazia 90% do que ele precisava direto da caixa. Gratuitamente.Invoice Ninja existed, was open-source, and did 90% of what he needed out of the box. For free.
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.Buy SaaS until the subscription tax, data ownership, or workflow mismatch genuinely bites; build custom when the tool is core to how the business wins.
Aquele telefonema me assombra um pouco. Porque a resposta honesta é: eu cometi o erro oposto também. Seahawk tinha um projeto em 2019 onde gastamos oito meses costurando cinco ferramentas SaaS diferentes -- Airtable, Zapier, Typeform, HubSpot, e um CMS Webflow customizado -- para gerenciar um workflow de cliente que, em retrospecto, um build customizado de £15.000 teria resolvido limpa e permanentemente. 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 para você uma regra limpa -- "sempre construa", "nunca construa" -- está vendendo algo. Então aqui está o framework real que uso quando um fundador 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 é núcleo da sua vantagem competitiva -- a razão pela qual clientes escolherão você em vez da próxima aba no navegador -- então construir provavelmente faz sentido. Se é infraestrutura, admin, ou funcionalidade de commodity, comprar é quase certamente mais barato em termos reais.reason customers 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.
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.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 é um pagamento único. Você fica preso 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 cuida disso para você. Você constrói, você é dono, incluindo os alertas 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 lead engineer sair, a próxima pessoa precisa aprender seu codebase. Isso são semanas de tempo billable.If your lead engineer leaves, the next person needs to learn your codebase. That's weeks of billable time.
- Feature creep. Stakeholders veem uma ferramenta customizada e assumem que ela pode fazer tudo. O escopo expande. Os custos seguem.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 francamente falhando. Isso não é uma razão para nunca construir -- é uma razão para entrar de olhos bem abertos.Standish Group's CHAOS Report has 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 início do ano tem o hábito engraçado de se tornar £490/mês em três anos -- uma vez que você está em um tier mais alto, você adicionou assentos, e o vendor fez uma "reestruturação de preço" (leia: aumento). Eu vi isso acontecer com clientes em Salesforce, Intercom, e Mixpanel. Não é malicioso. É apenas como a economia de 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.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 que via Zapier não é um sistema. É uma responsabilidade. 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 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.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 isso -- para funções de commodity, SaaS é quase sempre a jogada certa. Entrega de email? Postmark ou SendGrid. Pagamentos? Stripe, obviamente. Auth? Auth0 ou Clerk. Ninguém deveria estar construindo seu próprio processador de pagamentos em 2024.Postmark or 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 é a coisa que torna seu produto genuinamente diferente -- construir vale séria consideração. 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."
Passo pelo menos duas horas pesquisando o mercado de SaaS antes de recomendar um desenvolvimento customizado. Product Hunt e G2 são genuinamente úteis aqui -- não como verdade absoluta, mas como um inventário inicial.Product Hunt and 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. Um desenvolvimento customizado leva semanas no mínimo, geralmente meses. Se a 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.
Em 2022, Seahawk trabalhou com uma startup de logística que queria um dashboard customizado de otimização de rotas. Convencemos a usar uma camada de API white-label primeiro (usaram Route4Me como ponto de partida). Seis meses depois, sabiam exatamente quais três funcionalidades seus clientes realmente se importavam. O desenvolvimento customizado que eventualmente contrataram tinha metade do escopo -- e era duas vezes melhor -- porque aprenderam em produção em vez de em um documento de especificações.Route4Me as 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á com problemas. Não é hipotético -- vi fundadores 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.If you're selling a SaaS product, you can't outsource the thing you're selling.
- 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.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 contratar uma construção customizada.This is the best possible position to be in before commissioning a custom build.
- 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.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 função é infraestrutura de commodities -- email, pagamentos, autenticação, armazenamento, analytics.
- 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.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 as peças de commodities agressivamente, e construa a camada fina de lógica diferenciada por cima. Seu CRM é HubSpot. Seu suporte é Intercom. Mas o motor de workflow sob medida que os conecta e automatiza seu processo específico? Isso são duas semanas de dev customizado, não seis meses.
Em 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%. Construímos os 20% que importam. É conselho chato. É também o conselho que mais funcionou.WordPress -- a bought platform -- with custom plugins that do genuinely novel things. The platform handles the 80%. We build the 20% that matters. It's boring advice. It's also the advice that's worked most often.
---
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 a si mesmo se esse requisito é realmente necessário agora ou se é um nice-to-have que você elevou a um bloqueador. Se é verdadeiramente necessário e verdadeiramente não atendido, esse é um sinal que vale a pena levar a sério.necessary right now or 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 a base de código profundamente, e um segundo desenvolvedor ou uma agência retida que possa cobrir quando ele não está disponível. Possuir software customizado com um único freelancer e nenhum backup é uma posição frágil. Vi isso causar dano operacional real quando essa pessoa fica indisponível -- férias, doença, uma oferta 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 é dono da infraestrutura e ainda precisa de alguém técnico para gerenciá-la. Não é grátis -- é apenas mais barato para começar.Metabase for 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 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.your answer, specific to your stage, your team, your competitive position, and what you've actually validated so far.
O que eu questionaria é o romantismo em torno de construir. Software customizado não é inerentemente mais sério, mais escalável ou mais impressionante que uma stack bem configurada de SaaS. O founder de invoicing que mencionei no começo? Ele eventualmente construiu algo genuinamente customizado -- mas apenas depois de dezoito meses usando Invoice Ninja que lhe ensinaram exatamente o que seus clientes realmente precisavam. A construção ficou melhor pela espera.
Comece com a opção entediante. Ganhe o direito de construir algo novo.