# Quando subcontratar e quando dizer “isto não fazemos” Source: https://baqueiro.es/pt/la-sala-de-maquinas/quando-subcontratar-e-quando-dizer-nao/ Published: 2025-10-22T06:58:00+00:00 Updated: 2025-10-22T06:58:00+00:00 Author: Baqueiro Desarrollo Web Language: pt-PT Usage: Attribution required: quoting allowed with a visible link back --- **TL;DR** - Subcontratar tudo é perder o controlo; fazer tudo internamente é limitar o crescimento. - A decisão deve basear-se na estratégia, não na capacidade do momento. - Dizer “isto não fazemos” pode ser mais valioso para o cliente do que tentar e fazê-lo pela metade. Há 5 anos, um cliente pediu-nos uma app móvel nativa. Nunca tínhamos feito nenhuma. Mas pensámos: “Será assim tão difícil? Contratamos alguém que saiba, aprendemos pelo caminho e alargamos a nossa oferta”. Ao fim de 6 meses tínhamos perdido dinheiro, o cliente estava frustrado e a relação nunca recuperou. **Tirámos 2 lições duras:** 1. Não é o mesmo contratar alguém que sabe e delegar nessa pessoa e contratar alguém para te ensinar enquanto cobras como se já soubesses. 2. Dizer “não” a tempo sai mais barato do que dizer “sim” fora de tempo. Desde então temos uma regra clara para decidir o que fazemos internamente, o que subcontratamos e o que recusamos. Poupou-nos projetos falhados e permitiu-nos crescer sem perder qualidade. ## O triângulo da decisão: fazer, subcontratar ou recusar Cada projeto, ou cada parte de um projeto, encaixa numa destas 3 categorias: - **Fazemos nós:** é o nosso core. Dominamo-lo e acrescentamos valor real. - **Subcontratamos:** sabemos avaliá-lo e coordená-lo, mas não é a nossa especialidade; ou é, mas neste momento não temos capacidade. - **Recusamos:** está fora da nossa experiência ou há um conflito de interesses. A armadilha mais comum está na zona cinzenta entre subcontratar e recusar: aceitar projetos para os quais não temos a estrutura adequada e confiar que havemos de resolver pelo caminho. ## Quando fazer internamente Só fazemos internamente aquilo que sabemos mesmo fazer melhor do que a maioria. Para isso têm de se cumprir 4 condições: **É a nossa especialidade principal.** No nosso caso: WordPress e Elementor, WooCommerce, Laravel e automatizações com Python. **Conseguimos manter a qualidade sem sacrificar outros projetos.** Se um projeto encaixa nas nossas competências mas não na nossa capacidade, reforçamos a equipa temporariamente ou recusamo-lo. Não sacrificamos qualidade por volume. **A rentabilidade é razoável.** Alguns projetos que tecnicamente conseguimos fazer não têm margem suficiente para serem viáveis. Um projeto complexo com um orçamento apertado é pior negócio do que um simples com boa margem. **O cliente valoriza a nossa especialização.** Se o cliente pudesse contratar qualquer pessoa sem notar a diferença, estaríamos a concorrer só no preço. Preferimos projetos em que a nossa experiência concreta acrescenta um valor tangível. ## Quando subcontratar Subcontratamos em 3 situações: **1. Picos de capacidade.** Temos mais trabalho do que conseguimos executar, mas a procura é pontual. Recorremos a freelancers ou agências parceiras que já conhecemos. Não improvisamos com desconhecidos. **2. Especialidades adjacentes.** O projeto principal é o nosso core, mas inclui peças que não dominamos. Por exemplo, uma loja WooCommerce (o nosso trabalho) que precisa de fotografia de produto profissional (não é o nosso trabalho). Subcontratamos essa parte e somos nós a coordená-la. **3. Necessidades técnicas por fases.** Alguns projetos precisam, num momento concreto, de mais do que conseguimos cobrir. Por exemplo, uma migração massiva de dados que exige um perfil de sistemas (devops) durante umas semanas. É algo temporário, não estrutural. **A regra de ouro da subcontratação:** somos nós que mantemos a relação com o cliente e a responsabilidade pelo resultado. Não somos um intermediário que reencaminha emails. Somos o parceiro principal e respondemos por tudo o que entregamos. ## Quando dizer “isto não fazemos” Recusamos projetos em 4 situações: **1. Está fora da nossa especialidade.** Apps móveis nativas, desenvolvimento de hardware ou projetos de cibersegurança muito específicos, como testes de intrusão formais. Podíamos aprender, mas o cliente não deveria pagar a nossa curva de aprendizagem. **2. Há conflito de interesses.** Por exemplo, quando nos pedem para trabalhar para um concorrente direto de um cliente atual, ou quando o mais sensato para o cliente seria uma ferramenta SaaS que torna desnecessário um desenvolvimento à medida. Nesses casos não conseguimos ser imparciais, por isso dizemo-lo e, se for o caso, afastamo-nos. **3. Não conseguimos manter o que entregamos.** Desenvolver é metade do trabalho. Se não conseguimos oferecer uma manutenção de qualidade a longo prazo, o projeto vai acabar por falhar. Mais vale não começar. **4. O orçamento não chega para fazer bem.** Há projetos que só são viáveis se forem mal feitos. Esses não os fazemos. ## Como subcontratar sem perder qualidade nem a relação Quando subcontratamos, seguimos regras rigorosas: **Só com parceiros que já conhecemos.** Recomendados, testados e de confiança. Não fazemos experiências com o dinheiro do cliente. **Contratos claros.** O subcontratado assina um acordo de confidencialidade e um contrato que define âmbito, qualidade esperada, prazos e responsabilidades. Não deixamos nada à interpretação. São as mesmas [cláusulas técnicas que qualquer contrato de desenvolvimento deveria incluir](https://baqueiro.es/pt/seguridad-y-juridico/clausulas-tecnicas-contrato-desenvolvimento/). **Supervisão ativa.** Revemos o trabalho do subcontratado antes de chegar ao cliente. A responsabilidade final é nossa. **Transparência com o cliente.** Se uma parte relevante do projeto é feita por um parceiro, o cliente sabe-o desde a proposta. Não é preciso detalhar cada tarefa menor, mas nunca o escondemos. **Margem adequada.** Subcontratar tem custos de coordenação e risco. A nossa margem sobre o custo do subcontratado cobre isso. Não pretendemos ganhar o mesmo do que se o fizéssemos nós, mas também não trabalhar de graça a gerir terceiros. ## A armadilha do “podemos aprender” A tentação de aceitar projetos para aprender uma tecnologia nova é forte, sobretudo quando parecem interessantes ou rentáveis. Aprendemos a resistir-lhe. Aprender pelo caminho com o dinheiro de um cliente é eticamente questionável. O cliente não paga para ser o teu laboratório. Se queres alargar competências, investe em formação interna, em protótipos próprios ou em projetos-piloto com desconto em que o cliente sabe que se trata de algo experimental. O que fazemos, isso sim, é alargar o nosso core aos poucos. Há anos não fazíamos automatizações com Python. Começámos com projetos internos, depois com clientes que sabiam que estávamos a desenvolver essa área, e hoje é uma especialidade consolidada. Foi um processo controlado, não improvisação com projetos reais. ## Como comunicar “não fazemos” de forma profissional Recusar um projeto não é recusar o cliente. Na verdade, um “não” bem comunicado pode reforçar a relação. Uma resposta tipo: > “Este projeto concreto não encaixa na nossa especialidade porque [razão concreta]. Para isto recomendava-te falar com [contacto alternativo, se o tivermos]. Mantemo-nos em contacto para futuros projetos que encaixem naquilo que fazemos bem”. Essa mensagem explica o porquê, oferece uma alternativa e deixa a porta aberta. O cliente agradece a honestidade e a orientação, e é habitual que volte com outro projeto precisamente porque não aceitaste este. Desenvolvemos isto com mais detalhe em [como dizer “não” a um projeto (e o cliente agradecer-te)](https://baqueiro.es/pt/negocio-digital/como-dizer-nao-a-um-projeto/). ## O caso especial: white-label O trabalho white-label é um híbrido interessante. Outras agências contratam-nos para executar projetos que apresentam como seus. Tecnicamente é subcontratação, mas com uma dinâmica diferente: - A relação com o cliente final é da outra agência. - São eles que definem o âmbito. - Nós concentramo-nos na execução técnica. - A margem é menor, mas o volume pode compensar. O white-label funciona quando a outra agência sabe o que quer e precisa de execução. Falha quando espera que façamos o trabalho de consultoria que lhe cabe a ela. Por isso filtramos muito e só aceitamos projetos bem definidos. Antes de começar, pedimos um brief fechado e acordamos quem responde a quê quando o cliente final pede alterações. ## Perguntas frequentes ### Não é melhor dizer que fazemos tudo e depois subcontratar? É uma estratégia comum e perigosa. O cliente contrata-te pela especialização que prometes. Se depois descobre que essa parte é feita por outro, a confiança quebra-se. Preferimos ser claros desde o início. ### Como encontras bons subcontratados? Por referências e relações anteriores. Quase todos os nossos parceiros vêm de termos coincidido em algum projeto ou de recomendações de pessoas de confiança. Antes de delegar algo crítico, começamos com um trabalho pequeno e vemos como trabalham: prazos, comunicação, qualidade do código e como reagem quando algo corre mal. ### O que acontece se um subcontratado falhar? Respondemos perante o cliente. Resolvemos com outro parceiro, fazemos nós ou renegociamos. Esse risco faz parte do que cobramos. ### Devia fazer crescer a equipa interna em vez de subcontratar? Depende de a procura ser estrutural ou pontual. Se precisas constantemente de mais capacidade em algo concreto, contrata. Se é um pico pontual ou uma especialidade que usas de vez em quando, subcontrata. Já vimos agências meterem-se em sérios problemas por contratarem pessoas para uma procura temporária. Aprofundamos este critério em [quando externalizar e quando contratar](https://baqueiro.es/pt/negocio-digital/externalizar-ou-contratar-pt/). ## Conclusão Saber o que fazes, o que subcontratas e o que recusas **é definir quem és**. Tentar ser tudo para todos é a receita da mediocridade. Nós somos bons em desenvolvimento web, e-commerce e automatizações. Para o resto, temos parceiros ou dizemos que não. Essa clareza permite-nos fazer bem o que fazemos e manter clientes que sabem o que esperar. Na Baqueiro trabalhamos como parceiro tecnológico white-label para agências que querem alargar a sua oferta sem improvisar. Se estás a redefinir os limites da tua agência ou precisas de um parceiro para aquilo que não é o teu core, [falemos](https://baqueiro.es/pt/contacto/).