Cuándo subcontratar y cuándo decir «esto no lo hacemos»

Hace 5 años, un cliente nos pidió una app móvil nativa. Nunca habíamos hecho una. Pero pensamos: «¿Tan difícil puede ser? Contratamos a alguien que sepa, aprendemos sobre la marcha y ampliamos nuestra oferta».

Al cabo de 6 meses habíamos perdido dinero, el cliente estaba frustrado y la relación nunca se recuperó.

Sacamos 2 lecciones duras:

1. No es lo mismo contratar a alguien que sabe y delegar en él que contratar a alguien para que te enseñe mientras cobras como si ya supieras.
2. Decir «no» a tiempo sale más barato que decir «sí» a destiempo.

Desde entonces tenemos una regla clara para decidir qué hacemos internamente, qué subcontratamos y qué rechazamos. Nos ha ahorrado proyectos fallidos y nos ha permitido crecer sin perder calidad.

El triángulo de la decisión: hacer, subcontratar o rechazar

Cada proyecto, o cada parte de un proyecto, entra en una de estas 3 categorías:

• Lo hacemos nosotros: es nuestro core. Lo dominamos y aportamos valor real.
• Lo subcontratamos: sabemos evaluarlo y coordinarlo, pero no es nuestra especialidad; o sí lo es, pero ahora mismo no tenemos capacidad.
• Lo rechazamos: está fuera de nuestra experiencia o hay un conflicto de intereses.

La trampa más común está en la zona gris entre subcontratar y rechazar: aceptar proyectos para los que no tenemos la estructura adecuada y confiar en que ya lo resolveremos por el camino.

Cuándo hacerlo internamente

Solo hacemos dentro lo que de verdad sabemos hacer mejor que la mayoría. Para eso tienen que cumplirse 4 condiciones:

Es nuestra especialidad principal. En nuestro caso: WordPress y Elementor, WooCommerce, Laravel y automatizaciones con Python.

Podemos mantener la calidad sin sacrificar otros proyectos. Si un proyecto encaja con nuestras habilidades pero no con nuestra capacidad, reforzamos el equipo de forma temporal o lo rechazamos. No sacrificamos calidad por volumen.

La rentabilidad es razonable. Algunos proyectos que técnicamente podemos hacer no tienen margen suficiente para ser viables. Un proyecto complejo con un presupuesto ajustado es peor negocio que uno sencillo con buen margen.

El cliente valora nuestra especialización. Si el cliente pudiera contratar a cualquiera sin notar la diferencia, estaríamos compitiendo solo en precio. Preferimos proyectos en los que nuestra experiencia concreta aporta un valor tangible.

Cuándo subcontratar

Subcontratamos en 3 situaciones:

1. Picos de capacidad. Tenemos más trabajo del que podemos ejecutar, pero la demanda es puntual. Recurrimos a freelancers o agencias partner que ya conocemos. No improvisamos con desconocidos.

2. Especialidades adyacentes. El proyecto principal es nuestro core, pero incluye piezas que no dominamos. Por ejemplo, una tienda WooCommerce (lo nuestro) que necesita fotografía de producto profesional (no lo nuestro). Subcontratamos esa parte y la coordinamos nosotros.

3. Necesidades técnicas por fases. Algunos proyectos necesitan, en un momento concreto, más de lo que podemos cubrir. Por ejemplo, una migración masiva de datos que requiere un perfil de sistemas (devops) durante unas semanas. Es algo temporal, no estructural.

La regla de oro de la subcontratación: nosotros mantenemos la relación con el cliente y la responsabilidad del resultado. No somos un intermediario que reenvía correos. Somos el partner principal y respondemos de todo lo que entregamos.

Cuándo decir «esto no lo hacemos»

Rechazamos proyectos en 4 situaciones:

1. Está fuera de nuestra especialidad. Apps móviles nativas, desarrollo de hardware o proyectos de ciberseguridad muy específicos, como auditorías de intrusión formales. Podríamos aprender, pero el cliente no debería pagar nuestra curva de aprendizaje.

2. Hay conflicto de intereses. Por ejemplo, cuando nos piden trabajar para un competidor directo de un cliente actual, o cuando lo más sensato para el cliente sería una herramienta SaaS que hace innecesario un desarrollo a medida. En esos casos no podemos ser imparciales, así que lo decimos y, si procede, nos apartamos.

3. No podemos mantener lo que entregamos. Desarrollar es la mitad del trabajo. Si no podemos ofrecer un mantenimiento de calidad a largo plazo, el proyecto acabará fallando. Mejor no empezar.

4. El presupuesto no alcanza para hacerlo bien. Hay proyectos que solo son viables si se hacen mal. Esos no los hacemos.

Cómo subcontratar sin perder calidad ni la relación

Cuando subcontratamos, seguimos reglas estrictas:

Solo con partners que ya conocemos. Recomendados, probados y de confianza. No experimentamos con el dinero del cliente.

Contratos claros. El subcontratista firma un acuerdo de confidencialidad y un contrato que define alcance, calidad esperada, plazos y responsabilidades. No dejamos nada a la interpretación. Son las mismas cláusulas técnicas que debería incluir cualquier contrato de desarrollo.

Supervisión activa. Revisamos el trabajo del subcontratista antes de que llegue al cliente. La responsabilidad final es nuestra.

Transparencia con el cliente. Si una parte relevante del proyecto la hace un partner, el cliente lo sabe desde la propuesta. No hace falta detallar cada tarea menor, pero nunca lo ocultamos.

Margen adecuado. Subcontratar tiene costes de coordinación y riesgo. Nuestro margen sobre el coste del subcontratista cubre eso. No pretendemos ganar lo mismo que si lo hiciéramos nosotros, pero tampoco trabajar gratis gestionando a terceros.

La trampa del «podemos aprender»

La tentación de aceptar proyectos para aprender una tecnología nueva es fuerte, sobre todo cuando parecen interesantes o rentables. Hemos aprendido a resistirla.

Aprender sobre la marcha con el dinero de un cliente es éticamente cuestionable. El cliente no paga para ser tu laboratorio. Si quieres ampliar capacidades, invierte en formación interna, en prototipos propios o en proyectos piloto con descuento en los que el cliente sabe que se trata de algo experimental.

Lo que sí hacemos es ampliar nuestro core poco a poco. Hace años no hacíamos automatizaciones con Python. Empezamos con proyectos internos, después con clientes que sabían que estábamos desarrollando esa área, y hoy es una especialidad consolidada. Fue un proceso controlado, no improvisación con proyectos reales.

Cómo comunicar «no lo hacemos» de forma profesional

Rechazar un proyecto no es rechazar al cliente. De hecho, un «no» bien comunicado puede reforzar la relación. Una respuesta tipo:

«Este proyecto concreto no encaja con nuestra especialidad porque [razón concreta]. Para esto te recomendaría hablar con [contacto alternativo, si lo tenemos]. Sigamos en contacto para futuros proyectos que sí encajen con lo que hacemos bien».

Ese mensaje explica el porqué, ofrece una alternativa y deja la puerta abierta. El cliente agradece la honestidad y la orientación, y es habitual que vuelva con otro proyecto precisamente porque no aceptaste este. Lo desarrollamos con más detalle en cómo decir «no» a un proyecto (y que el cliente te lo agradezca).

El caso especial: white-label

El trabajo white-label es un híbrido interesante. Otras agencias nos contratan para ejecutar proyectos que presentan como propios. Técnicamente es subcontratación, pero con una dinámica distinta:

• La relación con el cliente final es de la otra agencia.
• Ellos definen el alcance.
• Nosotros nos centramos en la ejecución técnica.
• El margen es menor, pero el volumen puede compensarlo.

El white-label funciona cuando la otra agencia sabe lo que quiere y necesita ejecución. Falla cuando espera que hagamos el trabajo de consultoría que le corresponde a ella.

Por eso filtramos mucho y solo aceptamos proyectos bien definidos. Antes de empezar, pedimos un brief cerrado y acordamos quién responde a qué cuando el cliente final pide cambios.

Preguntas frecuentes

¿No es mejor decir que lo hacemos todo y luego subcontratar?

Es una estrategia común y peligrosa. El cliente te contrata por la especialización que prometes. Si después descubre que esa parte la hace otro, la confianza se rompe. Preferimos ser claros desde el principio.

¿Cómo encuentras buenos subcontratistas?

Por referencias y relaciones previas. Casi todos nuestros partners vienen de haber coincidido en algún proyecto o de recomendaciones de gente de confianza. Antes de delegar algo crítico, empezamos con un encargo pequeño y vemos cómo trabajan: plazos, comunicación, calidad del código y cómo reaccionan cuando algo sale mal.

¿Qué pasa si un subcontratista falla?

Respondemos ante el cliente. Lo resolvemos con otro partner, lo hacemos nosotros o renegociamos. Ese riesgo forma parte de lo que cobramos.

¿Debería crecer el equipo interno en lugar de subcontratar?

Depende de si la demanda es estructural o puntual. Si necesitas de forma constante más capacidad en algo concreto, contrata. Si es un pico puntual o una especialidad que usas de vez en cuando, subcontrata. Hemos visto agencias meterse en serios problemas por contratar personal para una demanda temporal. Profundizamos en este criterio en cuándo externalizar y cuándo contratar.

Conclusión

Saber qué haces, qué subcontratas y qué rechazas es definir quién eres. Intentar ser todo para todos es la receta de la mediocridad.

Nosotros somos buenos en desarrollo web, e-commerce y automatizaciones. Para lo demás, tenemos partners o decimos que no.

Esa claridad nos permite hacer bien lo que hacemos y mantener clientes que saben qué esperar.

En Baqueiro trabajamos como partner tecnológico white-label para agencias que quieren ampliar su oferta sin improvisar. Si estás redefiniendo los límites de tu agencia o necesitas un partner para lo que no es tu core, hablemos.