La auditoría que casi todo el mundo se salta en deals pequeños
Pregúntale a un comprador qué revisó antes de comprar un sitio de contenido de 40.000€ o una tienda Shopify de 150.000€, y te hablará de tendencias de tráfico, márgenes y condiciones con proveedores. Pregúntale qué revisó sobre la tecnología que hace funcionar el negocio, y la mayoría se queda callado. La due diligence técnica se percibe como cosa de deals SaaS grandes, con un CTO contratado para la ocasión — no como algo que necesita un comprador solo para un sitio WordPress o una tienda Shopify.
Y justo en ese punto ciego es donde viven las sorpresas post-adquisición. Un plugin que ya nadie mantiene. Una factura de hosting que se triplica en cuanto superas un umbral de tráfico que el vendedor nunca mencionó. Una "integración a medida" que resulta ser el proyecto personal de un freelance, sin documentar y sin posibilidad de renovación. Nada de esto aparece en una cuenta de resultados. Todo esto aparece en tus primeros 90 días como propietario.
Esta guía es una checklist técnica práctica para compradores que no son desarrolladores — qué preguntar, qué puedes probar tú mismo en veinte minutos, y cuándo merece la pena pagar a alguien para que mire debajo del capó.
Qué cubre la due diligence "técnica", según el tipo de negocio
La checklist se adapta a la plataforma. Un sitio de contenido en WordPress carga riesgos distintos a un producto SaaS con código propio.
| Tipo de negocio | Riesgos técnicos principales |
|---|---|
| Sitio de contenido / afiliación | Exceso de plugins, tema sin mantenimiento, dependencia del hosting, seguridad débil (contraseñas de admin flojas, sin copias de seguridad) |
| Shopify / e-commerce | Conflictos entre apps, calidad del código del tema personalizado, personalizaciones de pago/checkout, scripts de sincronización de stock |
| Producto SaaS | Arquitectura del código, cobertura de tests, deuda técnica, coste de infraestructura al escalar, dependencias de APIs |
| Newsletter / comunidad | Riesgo de migración de plataforma de envío, salud de la lista, automatizaciones a medida ligadas a la cuenta de una sola persona |
Sea cual sea la plataforma, se aplican las mismas seis preguntas — solo cambia la profundidad.
La checklist para no desarrolladores: 6 puntos que verificar antes de firmar
1. Salud del código y la arquitectura. No necesitas saber leer código para evaluar esto. Pregúntale al vendedor: ¿qué antigüedad tiene el código, ha pasado por una reescritura importante, existe alguna documentación más allá de "funciona y ya está"? Para un SaaS en concreto, pregunta si hay cobertura de tests y si los despliegues dependen obligatoriamente del fundador, o si alguien más del equipo puede publicar un cambio. Un código que solo una persona puede tocar sin riesgo es un riesgo de persona clave disfrazado de problema técnico. 2. Hosting e infraestructura. Pide la factura real de hosting, no una estimación. Pregunta qué pasa con esa factura si el tráfico o el uso se duplica — algunas configuraciones escalan de forma lineal, otras se caen por un precipicio. Comprueba si el sitio depende de un único servidor sin redundancia, y quién es el titular de la cuenta de hosting (si es la cuenta personal del vendedor, es una dependencia que hay que gestionar el día del traspaso). 3. Dependencias de terceros y riesgo de API. Cada integración es una promesa de una empresa con la que no tienes contrato. Haz una lista de todas las APIs y plugins de terceros de los que depende el negocio para funcionar — pagos, envíos, email, analítica — y comprueba dos cosas: si la integración se mantiene activamente, y qué se rompe si ese proveedor cambia sus precios o cierra su plan gratuito. Un negocio que depende silenciosamente de una API obsoleta está a una actualización de tener el checkout roto. 4. Postura de seguridad. No hace falta un test de penetración para un deal pequeño. Revisa lo básico: ¿está activada la autenticación en dos pasos en las cuentas de admin?, ¿cuándo se cambiaron las contraseñas por última vez?, ¿hay algún registro de una brecha anterior o de actividad de inicio de sesión inusual?, y — específicamente para e-commerce — ¿el checkout cumple con PCI a través del procesador de pago en lugar de almacenar los datos de tarjeta directamente? (la mayoría de los stacks de Shopify y e-commerce modernos lo gestionan por defecto, pero es en los checkouts a medida donde suele fallar). 5. Cumplimiento de licencias open-source. Si el producto es software a medida, pregunta si usa componentes open-source bajo licencia copyleft (tipo GPL) que puedan limitar tu capacidad de comercializar o modificar el código. Es un riesgo menor para un simple sitio de contenido, pero real para la compra de un SaaS — un informe de análisis de composición de software, si el vendedor puede generarlo, responde a esto en minutos. 6. Quién es realmente el dueño del código. Confirma que cualquier desarrollador, freelance o agencia que construyó el sitio o producto firmó un acuerdo cediendo la propiedad intelectual al negocio — sin conservar derechos personales sobre el código. Es fácil pasarlo por alto y caro descubrirlo después del cierre, cuando un antiguo freelance reclama la propiedad de una función central.Señales de alerta que merece la pena revisar con calma
| Señal | Por qué importa |
|---|---|
| El vendedor no sabe decir quién más podría hacer cambios en el sitio | Punto único de fallo técnico |
| Cuentas de hosting o desarrollo a nombre personal, no transferibles | Riesgo el día del traspaso, posible interrupción del servicio |
| Sin copias de seguridad, o copias nunca probadas | Una mala actualización y se pierde todo |
| Código a medida sin ninguna documentación | Cada cambio futuro se convierte en una apuesta cara |
| Reticencia a compartir accesos de admin/hosting antes del cierre | Suele indicar algo que prefieren que no veas |
Ninguna de estas señales mata el deal automáticamente. Son variables de precio y negociación — un negocio con deuda técnica real puede seguir siendo una buena compra, al precio correcto y con el acompañamiento adecuado del vendedor en la transición.
No necesitas ser desarrollador para hacer esta auditoría
Para un sitio de contenido sencillo o una tienda Shopify, la checklist de arriba es sobre todo una conversación más veinte minutos de prueba por tu cuenta: entra al panel de administración, revisa la autenticación en dos pasos, pide la factura de hosting y busca en la lista de plugins o apps cualquier cosa marcada como descontinuada.
Para la compra de un SaaS con código propio de verdad, merece la pena pagar unas horas a un revisor técnico independiente — alguien sin ningún interés en que el deal se cierre, para que su valoración sea honesta. Las plataformas freelance hacen esto accesible incluso para deals más modestos: una revisión técnica enfocada de una base de código pequeña suele costar una fracción de lo que te costaría una mala sorpresa post-adquisición. Pide específicamente una revisión de arquitectura, cobertura de tests, riesgo de dependencias y, si aplica, un chequeo de licencias open-source — no una "revisión de código" genérica.
Dónde encaja esto en tu calendario de due diligence
- Antes de la LOI: haz las seis preguntas anteriores por escrito; una respuesta vaga o evasiva es una señal de negociación, no solo un motivo para huir.
- Durante la due diligence: pide acceso de solo lectura o en sandbox al panel de admin, al panel de hosting y al código (para un SaaS) para verificar en lugar de creer sin más.
- En el contrato de compra: deja por escrito la cesión de propiedad intelectual y las condiciones de traspaso de accesos — quién entrega qué, y cuándo.
- Los primeros 90 días: cambia todas las credenciales a las que tenía acceso el vendedor, monta tus propias copias de seguridad si no existían, y empieza tu propia documentación a medida que aprendes el sistema, para que el siguiente propietario (aunque seas tú dentro de dos años) no empiece desde cero.
Preguntas frecuentes
¿Necesito formación técnica para comprar un negocio online?No, pero necesitas una checklist y la disposición a hacer preguntas concretas en lugar de aceptar un "funciona genial, no te preocupes". La mayoría de las comprobaciones anteriores toman minutos y no requieren saber programar.
¿La due diligence técnica solo aplica a compras de SaaS?No. Un sitio de contenido o una tienda e-commerce también tienen riesgo técnico real — solo que está concentrado en el hosting, los plugins y los accesos en lugar de en código a medida.
¿Cuánto cuesta una revisión técnica independiente?Depende del tamaño y la complejidad del código, desde una revisión ligera para un sitio pequeño hasta una auditoría más completa para un SaaS maduro. Pide un presupuesto acotado antes de comprometerte en lugar de asumir una tarifa fija.
¿Cuál es la pregunta con más impacto que le puedes hacer a un vendedor?"Si desaparecieras mañana, ¿quién más podría entrar y mantener esto funcionando?" La respuesta dice más sobre el riesgo técnico que casi cualquier otra cosa de esta lista.
¿Esto es asesoramiento legal o financiero?No — es un panorama educativo general para compradores que evalúan anuncios en Flipagora. Confirma la propiedad intelectual, las licencias y las condiciones de traspaso de accesos con un profesional cualificado antes de firmar nada.
La due diligence técnica es una de las comprobaciones más baratas de hacer antes de una adquisición, y una de las más caras de saltarse. Añade estas seis preguntas a tu proceso antes de ir a ver deals — empieza por las ofertas en Flippa si no sabes por dónde arrancar, y crea una alerta de deals para hacer estas preguntas pronto, no después de haberte enamorado ya de un anuncio.