Cómo subcontratar desarrollo web sin perder el control de su marca

Subcontratar desarrollo web es una decisión que muchas agencias toman tarde y con prisa: cuando el trabajo ya se acumuló, el cliente espera y nadie tiene tiempo de definir cómo se va a trabajar. Bien hecha, la subcontratación amplía su capacidad de entrega, le permite ofrecer servicios que no son su especialidad (desarrollo a medida, embudos, CRM, automatización, inteligencia artificial) y deja la relación con el cliente donde debe estar: en sus manos. Mal hecha, expone a su cliente, su margen y su marca.

Esta guía está escrita para dueños y directores de agencias y para quienes coordinan la entrega. No describe un proveedor ideal; ofrece criterios: cuándo conviene subcontratar, qué delegar, cómo definir el alcance, cómo controlar la calidad, qué debe quedar escrito sobre código, accesos y confidencialidad, qué modelo de colaboración elegir y qué señales de alerta buscar antes de firmar.

Subcontratar es una respuesta a un problema de capacidad o de especialidad, no a un problema de organización. Suele tener sentido cuando:

• Hay picos de trabajo que no justifican ampliar la nómina de forma permanente.
• Un proyecto requiere una especialidad que su equipo no tiene y que no necesitará de forma continua: integraciones, automatización, desarrollo a medida, optimización de rendimiento.
• Quiere ofrecer un servicio nuevo a sus clientes antes de decidir si conviene construirlo internamente.
• Necesita continuidad para cubrir ausencias o rotación sin detener las entregas.

Conviene pensarlo dos veces cuando:

• Sus procesos de brief, aprobación y entrega no están definidos. Un socio externo no puede corregir un alcance que usted mismo no tiene claro; solo hará visible el desorden, y con costo.
• Nadie en su agencia puede revisar el trabajo, ni siquiera a nivel de producto: qué se pidió, qué se entregó y qué falta. Sin esa revisión usted no controla la calidad, la recibe.
• El trabajo es el centro de lo que distingue a su agencia ante sus clientes. Aquello que le da identidad rara vez conviene delegarlo por completo.

Tampoco conviene ignorar los costos ocultos. Coordinar, explicar el contexto, revisar y corregir también consumen horas de su equipo, y la dependencia de un proveedor es un riesgo que se gestiona con contratos y documentación, no con confianza.

Como regla, delegue lo que se puede definir con claridad, se repite o requiere una especialidad, y es verificable al recibirlo. Conserve la estrategia, la relación con el cliente y la aprobación final. Estas son las áreas donde más se subcontrata, con lo que conviene vigilar en cada una:

• Desarrollo web y sitios a medida. Sitios nuevos, funciones personalizadas e integraciones con otros sistemas. Pida un entorno de pruebas visible desde el inicio. En desarrollo web se detalla lo que implica un proyecto de este tipo.
• Embudos y landing pages. Requieren coordinación entre diseño, textos, formularios, medición y CRM; defina quién redacta y quién conecta cada pieza.
• Secuencias de marketing. Correo, SMS y WhatsApp con condiciones de salida, consentimiento y medición. Revise los textos y los disparadores antes de activarlas: en las secuencias y la automatización de marketing el riesgo está más en las reglas que en la técnica.
• CRM y automatización. Configuración de etapas, campos y flujos. El mayor riesgo es dejar procesos que solo entiende quien los construyó, así que exija documentación.
• Asistentes de IA y chatbots. Exigen definir qué pueden responder, con qué fuentes y cuándo pasan a una persona; la supervisión posterior forma parte del trabajo.
• SOPs y onboarding. Documentar y automatizar los procesos de su propia agencia o los de un cliente. Si el objetivo es ordenar cómo su agencia recibe, ejecuta y entrega el trabajo, onboarding y SOPs es el servicio relacionado.
• Optimización de velocidad y SEO técnico. Tareas muy técnicas y acotadas que se prestan bien a un especialista.

En todos los casos la pregunta de fondo es la misma: ¿qué parte de esto puedo describir, revisar y aceptar con criterios claros?

En un esquema de marca blanca (white label), el socio trabaja detrás de su agencia: el cliente final conversa con usted, recibe los entregables con su identidad y no necesita saber quién construyó cada pieza. Es una práctica habitual en servicios de desarrollo, pero solo funciona si las reglas están claras. Lo que conviene dejar escrito antes de empezar:

• Quién habla con el cliente final. Por defecto, solo su agencia. Si en algún momento el socio participa en una reunión técnica, defina cómo se presenta y quién autoriza esa participación.
• Cómo se presentan los entregables. Documentos, correos, entornos de prueba y firmas con su identidad o con la del socio, según lo que usted decida.
• Confidencialidad. Un acuerdo que cubra la información del cliente, la suya y el trabajo en curso, además de cómo se manejan los datos personales.
• No solicitación. Que el socio no ofrezca servicios directamente a sus clientes durante la relación ni durante un tiempo razonable después.
• Créditos y portafolio. Si el socio puede mencionar el proyecto como parte de su trabajo o no. Lo prudente es que no pueda hacerlo sin autorización.
• Responsabilidad. Quién responde ante el cliente si algo falla (usted) y cómo se traslada esa responsabilidad al proveedor en el contrato entre ambos.

Estos puntos se formalizan con su asesor legal; esta guía solo señala qué temas conviene cubrir.

Muchos de los problemas de subcontratación nacen en el brief, no en el código. Un brief mínimo para un proyecto de desarrollo incluye:

• Objetivo del proyecto, expresado en términos del negocio del cliente (qué debe lograr el sitio o la automatización) y no solo en términos técnicos.
• Alcance: páginas, funciones, integraciones, idiomas y países.
• Exclusiones explícitas: lo que no se hará, como la redacción de contenidos, la fotografía, la migración de datos antiguos o el soporte más allá del periodo acordado.
• Entregables por etapa: diseños aprobados, entorno de pruebas, versión final, documentación y capacitación.
• Criterios de aceptación: condiciones verificables para dar por terminado cada entregable, por ejemplo "el formulario envía a la dirección acordada y crea el contacto en el CRM".
• Insumos del cliente y fechas: qué debe entregar el cliente (textos, imágenes, accesos) y qué pasa con el calendario si se demora.
• Dispositivos y navegadores que deben funcionar.
• Aprobaciones: quién aprueba en su agencia y en el cliente, y en cuánto tiempo debe responder.
• Gestión de cambios: cómo se solicita un cambio, cómo se estima su impacto en tiempo y costo y quién lo aprueba antes de ejecutarse.
• Plazos e hitos, con fechas de revisión.

Pida al socio una propuesta por escrito, con alcance, entregables y precio, sin letra pequeña. Si no es capaz de ponerlo por escrito, difícilmente podrá cumplirlo. Y apruebe el diseño antes de que empiece el desarrollo: es una de las formas más efectivas de evitar retrabajo, porque cambiar una pantalla en un diseño cuesta mucho menos que cambiarla cuando ya está programada.

Dos cosas separan una colaboración fluida de una conflictiva: cómo se comunica el equipo y cómo se revisa el trabajo.

Comunicación

• Un punto de contacto en cada lado, con un suplente.
• Un canal de trabajo acordado y una cadencia de avances, por ejemplo una actualización semanal por escrito.
• Un tablero o lista de tareas visible para ambos, con el estado real de cada elemento.
• Un registro de decisiones: lo acordado por llamada se confirma por escrito el mismo día.
• Una ruta de escalamiento: qué hacer si una fecha está en riesgo, quién decide y en cuánto tiempo se responde.
• Zonas horarias e idioma: horarios de coincidencia acordados y claridad sobre quién redacta o traduce la documentación técnica.

Control de calidad

Revise en hitos, no solo al final. Un orden razonable:

1. Diseño aprobado antes de empezar el desarrollo.
2. Revisiones parciales en un entorno de pruebas visible, con avances reales.
3. Pruebas en los dispositivos y navegadores principales de la audiencia del cliente.
4. Verificaciones de rendimiento antes del lanzamiento.
5. Prueba integral de formularios, integraciones, eventos de analítica y automatizaciones con datos de prueba.
6. Lanzamiento con una lista de verificación y un plan para revertir si algo sale mal.
7. Periodo de soporte posterior, con reglas claras sobre qué es un error y qué es un cambio nuevo.

La checklist de auditoría de sitio web sirve como base para la revisión previa al lanzamiento. Y si todavía no documenta cómo recibe y revisa las entregas, la guía de SOPs y onboarding ofrece la estructura para hacerlo: un procedimiento de recepción evita que la calidad dependa de quién revise ese día.

Aquí se rompen las relaciones mal planteadas. Defina por escrito cuatro temas.

Propiedad del código y del trabajo

• El código fuente completo, los diseños, la documentación y los activos creados para el proyecto pertenecen al cliente o a su agencia desde la entrega o el pago, según lo acordado.
• Los componentes de terceros (temas, plugins, librerías, fuentes, imágenes) están identificados, y sus licencias están a nombre del cliente o de su agencia.
• El proveedor no conserva ni reutiliza material del cliente fuera del proyecto sin autorización.

Accesos y cuentas

• El dominio, el hosting, la analítica, Search Console, el CRM, las cuentas de anuncios y los repositorios están a nombre del cliente o de su agencia. El socio entra como usuario con un rol, no como propietario.
• Los accesos se otorgan por invitación con rol y con verificación en dos pasos; las contraseñas no se comparten por chat ni por correo electrónico. Un gestor de contraseñas o los permisos delegados resuelven el problema.
• Cada persona recibe solo los accesos que necesita, y solo mientras dura la tarea.
• Al cerrar el proyecto se retiran los accesos y se confirma por escrito.

Continuidad

Hágase una pregunta incómoda: si este proveedor desapareciera mañana, ¿podría otro continuar el trabajo? Para que la respuesta sea sí, exija un repositorio con historial, documentación de instalación y despliegue, una lista de integraciones y claves guardadas en cuentas del cliente, copias de respaldo y un instructivo para quien administre el contenido.

Confidencialidad

Un acuerdo que cubra la información del cliente y la de su agencia, reglas para los datos personales (quién accede, dónde se almacenan, por cuánto tiempo) y la obligación de avisar si ocurre un incidente. Los detalles legales los define su asesor; si el cliente opera en un sector regulado, será su equipo legal o de cumplimiento quien fije los requisitos.

No hay un modelo superior a los demás; cada uno responde a un tipo de trabajo.

Proyecto con alcance cerrado

Un alcance, unos entregables, un calendario y un precio acordados de antemano. Funciona bien para construcciones con un resultado definido: un sitio, una tienda en línea, un embudo, una integración. Exige un buen brief y una gestión de cambios disciplinada; su riesgo principal es discutir qué estaba incluido.

Bolsa de horas

Un bloque de horas disponible para tareas variables. Es útil para mantenimiento, ajustes pequeños y urgencias. Requiere confianza y transparencia: registro de horas, prioridades claras y reglas sobre vencimiento y sobre tareas que superan la bolsa. Su riesgo es la falta de visibilidad: sin informes, nadie sabe en qué se fue el tiempo.

Acuerdo mensual (retainer)

Capacidad continua para operación y mejora: páginas nuevas, optimizaciones, automatizaciones, soporte. Da previsibilidad a ambas partes y permite que el socio conozca a fondo sus proyectos. Defina qué incluye, cómo se priorizan las solicitudes, qué informes recibirá y cómo se revisa o se termina el acuerdo.

Combinaciones

Con frecuencia el modelo adecuado es mixto: un proyecto para construir y un acuerdo mensual para operar y mejorar. Lo importante es que el cambio de modelo no cambie las reglas de propiedad, accesos y calidad.

Antes de firmar, haga estas preguntas y evalúe la calidad de las respuestas, no solo su contenido:

• ¿Cómo se define el alcance y cómo se gestionan los cambios?
• ¿Quién hará realmente el trabajo y quién lo supervisa?
• ¿Cómo se prueba antes del lanzamiento: dispositivos, navegadores, rendimiento?
• ¿Qué recibirá mi agencia al final: código fuente, documentación, accesos?
• ¿Qué ocurre si el proveedor deja de estar disponible?
• ¿Con qué frecuencia y por qué canal se informa el avance?
• ¿Cómo se manejan la confidencialidad y los datos personales?
• ¿Puedo hablar con la persona que coordinará mi cuenta?

Señales de alerta

• Promesas de posicionamiento o de ventas. Nadie puede prometer una posición en Google ni una cifra de ingresos.
• Ausencia de una propuesta escrita con alcance, entregables y precio, o presencia de letra pequeña.
• Un precio muy inferior al del resto sin una explicación clara de qué se deja fuera: pruebas, documentación, soporte o revisión.
• No está claro quién hace el trabajo ni quién responde.
• Resistencia a entregar el código fuente o a poner las cuentas a nombre del cliente.
• Piden contraseñas por mensajes o administran las cuentas del cliente como propietarios.
• Dicen que sí a todo, sin hacer preguntas sobre el negocio del cliente ni señalar riesgos.
• No tienen un proceso de pruebas ni de revisión previa al lanzamiento.
• Toda la comunicación pasa por intermediarios sin visibilidad técnica.
• Reaccionan con presión comercial ante dudas razonables.

Una buena señal, en cambio, es que el socio haga preguntas incómodas, diga que no a lo que no puede cumplir y le explique los compromisos en términos que usted pueda trasladar a su cliente.

Un socio de entrega es una extensión de su capacidad, no un reemplazo de su criterio. Para que las preguntas anteriores no queden en abstracto, así respondemos nosotros a las más importantes; puede tomarlas como referencia para comparar a cualquier proveedor:

• Quién supervisa. Victor J. Rosario atiende personalmente las llamadas y supervisa cada proyecto. No hay intermediarios, y él es bilingüe (español e inglés).
• Cómo se define el alcance. Después de una llamada de estrategia de 30 minutos, sin presión de venta, entregamos una propuesta escrita con alcance, entregables y precio, sin letra pequeña. Si no podemos ayudar, se lo decimos directamente.
• Cómo se trabaja. De forma remota con empresas de Latinoamérica, con proyectos de alcance definido y acuerdos mensuales de operación y mejora. El diseño se aprueba antes del desarrollo, y la construcción se prueba en los principales dispositivos y navegadores, con verificaciones de rendimiento antes de lanzar.
• Qué recibe al final. El código fuente completo y acceso a todo lo construido. Al lanzar un sitio, además, enviamos el sitio a Google, configuramos la analítica e incluimos capacitación y 30 días de soporte posterior.
• Cómo se paga. Con una factura enviada por Stripe, normalmente con un pago inicial al aprobar la propuesta y el resto a la entrega.
• Plazos. Entre 4 y 12 semanas según el alcance: un sitio web puede estar listo en unas 4 semanas, y un CRM con automatización integrada puede tomar de 8 a 12.

Si su criterio principal es el precio más bajo por hora de desarrollo, probablemente no somos la opción adecuada; nuestro trabajo está pensado para agencias que buscan un socio de entrega a largo plazo. Si su agencia necesita condiciones particulares, como confidencialidad, marca blanca o canales de comunicación específicos, la llamada de estrategia es el momento de plantearlas; si no podemos cumplirlas, se lo diremos con claridad. Para ver cómo trabajamos con agencias, revise la página dedicada a agencias; y para el detalle de lo que construimos, la de desarrollo web.