# Cando subcontratar e cando dicir “isto non o facemos” Source: https://baqueiro.es/gl/la-sala-de-maquinas/cando-subcontratar-e-cando-dicir-non/ Published: 2025-10-22T06:58:00+00:00 Updated: 2025-10-22T06:58:00+00:00 Author: Baqueiro Desarrollo Web Language: gl-ES Usage: Atribución requirida: permítese a cita cunha ligazón visible de volta --- **TL;DR** - Subcontratalo todo é perder o control; facelo todo dentro é limitar o crecemento. - A decisión debe basearse na estratexia, non na capacidade do momento. - Dicir “isto non o facemos” pode valerlle máis ao cliente que intentalo e facelo a medias. Hai 5 anos, un cliente pediunos unha app móbil nativa. Nunca fixeramos ningunha. Pero pensamos: “Tan difícil pode ser? Contratamos a alguén que saiba, aprendemos sobre a marcha e ampliamos a nosa oferta”. Ao cabo de 6 meses perderamos cartos, o cliente estaba frustrado e a relación nunca se recuperou. **Aprendemos 2 leccións duras:** 1. Non é o mesmo contratar a alguén que sabe e delegar nel que contratar a alguén para que che ensine mentres cobras coma se xa soubeses. 2. Dicir “non” a tempo sae máis barato que dicir “si” a destempo. Desde entón temos unha regra clara para decidir que facemos internamente, que subcontratamos e que rexeitamos. Aforrounos proxectos fallidos e permitiunos crecer sen perder calidade. ## O triángulo da decisión: facer, subcontratar ou rexeitar Cada proxecto, ou cada parte dun proxecto, entra nunha destas 3 categorías: - **Facémolo nós:** é o noso core. Dominámolo e achegamos valor real. - **Subcontratámolo:** sabemos avalialo e coordinalo, pero non é a nosa especialidade; ou si o é, pero agora mesmo non temos capacidade. - **Rexeitámolo:** está fóra da nosa experiencia ou hai un conflito de intereses. A trampa máis común está na zona gris entre subcontratar e rexeitar: aceptar proxectos para os que non temos a estrutura axeitada e confiar en que xa o resolveremos polo camiño. ## Cando facelo internamente Só facemos dentro o que de verdade sabemos facer mellor ca a maioría. Para iso teñen que cumprirse 4 condicións: **É a nosa especialidade principal.** No noso caso: WordPress e Elementor, WooCommerce, Laravel e automatizacións con Python. **Podemos manter a calidade sen sacrificar outros proxectos.** Se un proxecto encaixa coas nosas habilidades pero non coa nosa capacidade, reforzamos o equipo de forma temporal ou rexeitámolo. Non sacrificamos calidade por volume. **A rendibilidade é razoable.** Algúns proxectos que tecnicamente podemos facer non teñen marxe dabondo para seren viables. Un proxecto complexo cun orzamento axustado é peor negocio ca un sinxelo con boa marxe. **O cliente valora a nosa especialización.** Se o cliente puidese contratar a calquera sen notar a diferenza, estariamos competindo só en prezo. Preferimos proxectos nos que a nosa experiencia concreta achega un valor tanxible. ## Cando subcontratar Subcontratamos en 3 situacións: **1. Picos de capacidade.** Temos máis traballo do que podemos executar, pero a demanda é puntual. Recorremos a freelancers ou a axencias partner que xa coñecemos. Non improvisamos con descoñecidos. **2. Especialidades adxacentes.** O proxecto principal é o noso core, pero inclúe pezas que non dominamos. Por exemplo, unha tenda WooCommerce (o noso) que necesita fotografía de produto profesional (non o noso). Subcontratamos esa parte e coordinámola nós. **3. Necesidades técnicas por fases.** Algúns proxectos necesitan, nun momento concreto, máis do que podemos cubrir. Por exemplo, unha migración masiva de datos que require un perfil de sistemas (devops) durante unhas semanas. É algo temporal, non estrutural. **A regra de ouro da subcontratación:** nós mantemos a relación co cliente e a responsabilidade do resultado. Non somos un intermediario que reenvía correos. Somos o partner principal e respondemos de todo o que entregamos. ## Cando dicir “isto non o facemos” Rexeitamos proxectos en 4 situacións: **1. Está fóra da nosa especialidade.** Apps móbiles nativas, desenvolvemento de hardware ou proxectos de ciberseguridade moi específicos, como auditorías de intrusión formais. Poderiamos aprender, pero o cliente non debería pagar a nosa curva de aprendizaxe. **2. Hai conflito de intereses.** Por exemplo, cando nos piden traballar para un competidor directo dun cliente actual, ou cando o máis sensato para o cliente sería unha ferramenta SaaS que fai innecesario un desenvolvemento a medida. Neses casos non podemos ser imparciais, así que o dicimos e, se cómpre, apartámonos. **3. Non podemos manter o que entregamos.** Desenvolver é a metade do traballo. Se non podemos ofrecer un mantemento de calidade a longo prazo, o proxecto acabará fallando. Mellor non empezar. **4. O orzamento non chega para facelo ben.** Hai proxectos que só son viables se se fan mal. Eses non os facemos. ## Como subcontratar sen perder calidade nin a relación Cando subcontratamos, seguimos regras estritas: **Só con partners que xa coñecemos.** Recomendados, probados e de confianza. Non experimentamos cos cartos do cliente. **Contratos claros.** O subcontratista asina un acordo de confidencialidade e un contrato que define alcance, calidade esperada, prazos e responsabilidades. Non deixamos nada á interpretación. Son as mesmas [cláusulas técnicas que debería incluír calquera contrato de desenvolvemento](https://baqueiro.es/gl/seguridad-y-juridico/clausulas-tecnicas-contrato-desenvolvemento/). **Supervisión activa.** Revisamos o traballo do subcontratista antes de que chegue ao cliente. A responsabilidade final é nosa. **Transparencia co cliente.** Se unha parte relevante do proxecto a fai un partner, o cliente sábeo desde a proposta. Non fai falta detallar cada tarefa menor, pero nunca o ocultamos. **Marxe axeitada.** Subcontratar ten custos de coordinación e risco. A nosa marxe sobre o custo do subcontratista cobre iso. Non pretendemos gañar o mesmo que se o fixésemos nós, pero tampouco traballar de balde xestionando a terceiros. ## A trampa do “podemos aprender” A tentación de aceptar proxectos para aprender unha tecnoloxía nova é forte, sobre todo cando parecen interesantes ou rendibles. Aprendemos a resistila. Aprender sobre a marcha cos cartos dun cliente é eticamente cuestionable. O cliente non paga para ser o teu laboratorio. Se queres ampliar capacidades, inviste en formación interna, en prototipos propios ou en proxectos piloto con desconto nos que o cliente sabe que se trata de algo experimental. O que si facemos é ampliar o noso core aos poucos. Hai anos non faciamos automatizacións con Python. Empezamos con proxectos internos, despois con clientes que sabían que estabamos a desenvolver esa área, e hoxe é unha especialidade consolidada. Foi un proceso controlado, non improvisación con proxectos reais. ## Como comunicar “non o facemos” de forma profesional Rexeitar un proxecto non é rexeitar o cliente. De feito, un “non” ben comunicado pode reforzar a relación. Unha resposta tipo: > “Este proxecto concreto non encaixa coa nosa especialidade porque [razón concreta]. Para isto recomendaríache falar con [contacto alternativo, se o temos]. Sigamos en contacto para futuros proxectos que si encaixen co que facemos ben”. Esa mensaxe explica o porqué, ofrece unha alternativa e deixa a porta aberta. O cliente agradece a honestidade e a orientación, e é habitual que volva con outro proxecto precisamente porque non aceptaches este. Contámolo con máis detalle en [como dicir “non” a un proxecto (e que o cliente cho agradeza)](https://baqueiro.es/gl/negocio-digital/como-dicir-non-a-un-proxecto/). ## O caso especial: white-label O traballo white-label é un híbrido interesante. Outras axencias contrátannos para executar proxectos que presentan como propios. Tecnicamente é subcontratación, pero cunha dinámica distinta: - A relación co cliente final é da outra axencia. - Eles definen o alcance. - Nós centrámonos na execución técnica. - A marxe é menor, pero o volume pode compensala. O white-label funciona cando a outra axencia sabe o que quere e necesita execución. Falla cando espera que fagamos o traballo de consultoría que lle corresponde a ela. Por iso filtramos moito e só aceptamos proxectos ben definidos. Antes de empezar, pedimos un brief pechado e acordamos quen responde a que cando o cliente final pide cambios. ## Preguntas frecuentes ### Non é mellor dicir que o facemos todo e logo subcontratar? É unha estratexia común e perigosa. O cliente contrátate pola especialización que prometes. Se despois descobre que esa parte a fai outro, a confianza rompe. Preferimos ser claros desde o principio. ### Como atopas bos subcontratistas? Por referencias e relacións previas. Case todos os nosos partners veñen de coincidir nalgún proxecto ou de recomendacións de xente de confianza. Antes de delegar algo crítico, empezamos cun encargo pequeno e vemos como traballan: prazos, comunicación, calidade do código e como reaccionan cando algo sae mal. ### Que pasa se un subcontratista falla? Respondemos ante o cliente. Resolvémolo con outro partner, facémolo nós ou renegociamos. Ese risco forma parte do que cobramos. ### Debería medrar o equipo interno en lugar de subcontratar? Depende de se a demanda é estrutural ou puntual. Se necesitas de forma constante máis capacidade en algo concreto, contrata. Se é un pico puntual ou unha especialidade que usas de cando en vez, subcontrata. Vimos axencias meterse en serios problemas por contratar persoal para unha demanda temporal. Afondamos neste criterio en [cando externalizar e cando contratar](https://baqueiro.es/gl/negocio-digital/externalizar-ou-contratar/). ## Conclusión Saber que fas, que subcontratas e que rexeitas **é definir quen es**. Intentar selo todo para todos é a receita da mediocridade. Nós somos bos en desenvolvemento web, comercio electrónico e automatizacións. Para o demais, temos partners ou dicimos que non. Esa claridade permítenos facer ben o que facemos e manter clientes que saben que agardar. En Baqueiro traballamos como partner tecnolóxico white-label para axencias que queren ampliar a súa oferta sen improvisar. Se estás a redefinir os límites da túa axencia ou necesitas un partner para o que non é o teu core, [falemos](https://baqueiro.es/gl/contacto/).