Un socio de desarrollo white label se valida con seis criterios antes de firmar: NDA mutuo por escrito, propiedad total del código en un repositorio a nombre de tu agencia, proceso de QA documentado con entorno de staging, comunicación asíncrona en herramientas compartidas con al menos cuatro horas de solape horario, modelo de precios con desglose y referencias verificables de agencias como la tuya. Si el posible socio no firma un NDA, no entrega el repositorio, no describe su QA o cotiza un «desde» sin partidas, no avances: esas cuatro ausencias explican la mayoría de los proyectos white label que se estropean. A continuación: qué revisar en cada área, preguntas para la primera llamada, señales de alarma y un checklist final para decidir con datos.
Cómo evaluar a un socio de desarrollo white label
La evaluación tiene dos capas. La contractual cubre NDA, propiedad intelectual, pagos y salida; la operativa cubre QA, comunicación, herramientas y plazos. Ambas deben quedar por escrito antes del primer ticket, no después del primer problema. Un partner se presenta con tu marca y escribe código que tú garantizarás años después, así que la pregunta no es solo «¿codifican bien?», sino «¿puedo operar seis meses con esta gente sin sorpresas ni fugas?». El marco completo está en nuestra página de desarrollo web white label.
NDA: qué debe cubrir
El acuerdo de confidencialidad debe ser mutuo: protege a tu agencia y al socio por igual. Un NDA unilateral suele indicar que el otro lado negocia desde la desproporción. Debe definir qué es información confidencial (nombres de clientes, tarifas, roadmaps, credenciales, archivos de diseño), cuánto dura la obligación —lo habitual son dos a cinco años después de terminar la relación—, quiénes pueden acceder dentro de cada organización y qué ley aplica si hay conflicto.
Cuatro detalles que casi nadie revisa: la cláusula de no-solícito, que prohíbe al socio ofrecer servicios a tus clientes; el plazo para devolver el NDA firmado —veinticuatro a cuarenta y ocho horas es señal de seriedad—; el aviso ante cualquier filtración en plazo definido; y la aprobación previa por escrito para citarte como cliente o caso de éxito.
Propiedad del código fuente
Regla simple: el repositorio debe vivir en la organización de tu agencia desde el primer commit. Si el socio trabaja en su propio Git y «lo transfiere cuando esté listo», estás financiando un activo que no controlas: no puedes auditar el historial ni cambiar de proveedor a mitad de obra y, en el peor caso, el código queda rehén de una relación comercial que se deteriora. Pide administrador en tu organización, ramas protegidas con revisión y un registro de licencias de terceros (tema, plugins, librerías, tipografías) para saber qué es tuyo, qué es GPL y qué se renueva cada año.
Al mismo nivel quedan los accesos: dominio, hosting, DNS, analítica y correo transaccional deben estar en cuentas de la agencia o del cliente, nunca en cuentas personales del equipo del socio. Un desarrollador que se va no debe llevarse el proceso de despliegue. Añade requisito de documentación continua (README, variables de entorno, instrucciones de build, accesos de staging) y cambia la conversación: el socio pasa de «ya te lo mando al final» a operar como equipo tuyo desde la semana uno, que es exactamente el modelo que describimos en white-label web development.
Proceso de QA
Un socio sin QA te obliga a hacer de QA: cada entrega cae en tu equipo, se filtra al cliente final y la confianza se erosiona en cada publicación. Pregunta directa en la primera llamada: «¿cómo probáis antes de entregar?». La respuesta mínima aceptable menciona entorno de staging con URL protegida, checklist por tipo de tarea (formularios, navegación, responsive, compatibilidad entre navegadores), revisión cruzada entre desarrolladores, prueba en dispositivo real y una definición de «terminado» sin interpretaciones. Si amplías la revisión a accesibilidad —contraste, orden de foco, navegación por teclado— apóyate en las guías de accesibilidad de MDN: ahí el QA improvisado sale más caro.
Señales de QA real: errores reportados con pasos de reproducción, captura y prioridad; registro visible para tu equipo; plazos de corrección; pasada de regresión antes de cada publicación; y un presupuesto de rendimiento acordado con peso de página y umbrales de LCP e INP. Señales de QA de marketing: «lo reviso y te lo mando», «funciona en mi navegador» o una demostración en localhost sin staging.
Comunicación: herramientas y husos
El huso importa menos que el solape real: mínimo tres o cuatro horas al día en las que ambos equipos estén vivos para decidir rápido. Fuera de esa ventana la comunicación debe ser asíncrona y dejada por escrito; un ticket con contexto, capturas y criterio de aceptación vale más que tres mensajes de «¿tienes un minuto?». El stack mínimo: Slack o Teams por proyecto, un gestor de tickets, repositorio con cambios comentados, Figma para el diseño y una actualización diaria o cada 48 horas con lo hecho, lo bloqueado y lo siguiente.
Evita que el acuerdo viva solo en mensajería personal: no hay historial compartido, no hay SLA de respuesta y cuando la conversación se enreda no puedes demostrar qué se acordó. La promesa de respuesta en menos de X horas debe estar en la propuesta con la ventana horaria explícita; sin ventana, el «24/7» es decoración.
Modelo de precios
Tres modelos conviven en el mercado y cada uno encaja con un tipo de proyecto. Lo importante es que esté definido antes de empezar e incluya lo que muchas propuestas dejan fuera: QA, gestión, correcciones dentro del alcance y soporte post-lanzamiento.
| Modelo | Cuándo encaja | Riesgo a vigilar |
|---|---|---|
| Precio fijo por proyecto | Alcance cerrado y documentado: landing o sitio corporativo con pantallas definidas. | Cambios de alcance mal delimitados; si todo es «pequeño», el proyecto nunca cierra. |
| Por hora con tope mensual | Evoluciones y mantenimiento, o proyectos cuyos requisitos maduran durante el build. | Sin tope ni reporte semanal, la factura crece sin que lo notes. |
| Retainer de capacidad | Demanda continua, varios proyectos al año o picos previsibles de venta. | Horas pagadas y no usadas; define si se acumulan o se pierden. |
Exige además moneda y tipo de cambio si facturan en dólares, frecuencia de facturación, tarifa de urgencia y política de cancelación. Una tarifa muy por debajo del mercado no es ahorro: se paga con QA precario, código sin revisión y soporte inexistente, y el coste aparece cuando el cliente ya está mirando tu marca.
Señales de alarma
Estas señales, solas o combinadas, bastan para pausar la negociación:
| Señal | Qué suele esconder |
|---|---|
| No firman el NDA «hasta ver el proyecto» | Cultura débil de confidencialidad y riesgo real de fuga de tu cliente. |
| El código vive en su repositorio hasta la entrega final | Dependencia forzada e imposibilidad de cambiar de proveedor. |
| No existen staging ni checklist de QA | El control de calidad recae en tu agencia y, después, en el cliente. |
| Cotizan «desde» sin partidas ni supuestos | Sobrecosto al cierre o recortes invisibles para cuadrar el número. |
| Comunicación solo por mensajería personal | Sin historial compartido, sin SLA y sin trazabilidad de decisiones. |
| Se niegan a un piloto pequeño | Confían en el contrato grande, no en demostrar capacidad primero. |
Preguntas para la primera llamada
Prepara estas ocho preguntas antes de la llamada; las respuestas dicen más que cualquier portafolio:
- ¿Firmáis nuestro NDA antes de compartir alcance o estimaciones?
- ¿En qué organización vive el repositorio y quién es administrador?
- ¿Cómo definís «terminado» y quién aprueba cada entrega?
- ¿Qué incluye el precio: QA, gestión, soporte y garantía post-lanzamiento?
- ¿Cuántas rondas de corrección contempla el alcance y qué cuenta como cambio?
- ¿Cuál es el solape horario diario y quién responde fuera de él?
- ¿Ofrecéis un piloto de una o dos semanas antes del compromiso grande?
- ¿Qué pasa si cancelamos a mitad de proyecto: código, accesos y pagos?
Checklist final antes de firmar
- NDA mutuo firmado por ambas partes antes de compartir información sensible.
- Repositorio en la organización de la agencia, con administrador y ramas protegidas.
- Inventario de licencias de terceros (tema, plugins, tipografías) por escrito.
- Staging accesible y checklist de QA acordado, con dispositivos y navegadores a probar.
- Definición de «terminado», rondas incluidas y tratamiento de cambios de alcance.
- Stack de comunicación, SLA de respuesta y ventana de solape horario definidos.
- Modelo de precio con partidas, supuestos, moneda e impuestos explicitados.
- Dominio, hosting, DNS y analítica en cuentas de la agencia o del cliente.
Preguntas frecuentes
¿Cuánto dura la fase de prueba con un socio white label?
Dos semanas con alcance pequeño bastan para medir calidad, comunicación y plazos. Si el piloto sale limpio, el proyecto grande tiene base; si no, has pagado poco por aprenderlo.
¿Quién es dueño del código durante el proyecto?
Tú, desde el primer commit, si el repositorio está en tu organización y el contrato lo refleja. La transferencia «al final» es la excepción que conviene rechazar antes de firmar.
¿Qué hago si el socio no firma el NDA?
No compartas nombres de clientes, accesos ni propuestas. Sin NDA no hay base para proteger tu relación comercial y esa conversación debe terminar ahí mismo.
¿Es mejor pagar por proyecto u por hora?
Por proyecto con alcance cerrado; por hora con tope cuando el alcance evoluciona. Lo esencial es que existan tope, reporte periódico y reglas escritas para los cambios.
¿Cómo compruebo que su QA es real?
Pide tres cosas: el checklist que usan, una URL de staging activa y un ejemplo de reporte de errores con pasos y capturas. Si no existen, el QA existe solo en la presentación.
Guías relacionadas: Cuánto cuesta una página web en México en 2026 (precios reales) · Diseño web en CDMX para negocios