Due diligence antes de comprar un SaaS: el checklist de 27 puntos
Checklist de due diligence de 27 puntos para compradores de SaaS: producto, finanzas, clientes, legal, operaciones, crecimiento y traspaso. Salta uno de los cinco críticos y compras un pasivo.
Due diligence antes de comprar un SaaS: el checklist de 27 puntos
Es el décimo día de exclusividad. Un ex director de producto, tres semanas después de firmar un LOI por un micro-SaaS de analytics en 180.000 dólares, está en una llamada un jueves a la noche con un desarrollador amigo que aceptó revisar el repositorio. Esperaban hablar de versiones de framework y cobertura de tests. En cambio, el desarrollador señala una línea en la lista de proveedores: una única API de terceros que hace el trabajo central del producto, facturada por llamada, a una tarifa que —con los números de uso del propio vendedor— consume el 41% de los ingresos brutos. El P&L del vendedor la listaba como "infraestructura", incluida dentro de un 9%. Ese delta no es un redondeo. Ese delta es el negocio.
El LOI no cae esa noche. Cae ocho días después, cuando el comprador intenta renegociar el precio contra el margen reformulado y el vendedor se levanta de la mesa. Lo que el comprador perdió no fue el depósito —eso volvió—. Lo que perdió fueron tres meses de exclusividad, dos facturas de retainer a asesores legales y técnicos, y las siguientes tres operaciones que no pudo correr en paralelo. Todo se podía haber detectado en la fase pre-LOI con una sola pregunta, hecha en el orden correcto, sobre dónde va cada dólar de ingreso. Para eso sirve este checklist.
TL;DR. Veintisiete preguntas, agrupadas en siete categorías, secuenciadas en tres fases (filtro pre-LOI, análisis profundo post-LOI, verificación antes del cierre). Cubren producto, finanzas, clientes, legal, operaciones, crecimiento y traspaso. Cinco son motivos para caminar: si las saltas, no compraste un activo, compraste un pasivo. El resto son palancas para negociar precio.
Por qué 27 puntos, no 12
La guía pilar para comprar una startup en 2026 incluye una sección de due diligence con 12 preguntas. Esa lista es el filtro mínimo viable para cualquier activo digital: alcanza para que no termines comprando un dominio con una landing y llamándolo SaaS. Este post es lo que viene después. Veintisiete puntos, porque cuando hay un SaaS real con usuarios reales e ingresos recurrentes reales sobre la mesa, las fallas se vuelven más específicas y más caras, y doce preguntas ya no alcanzan para detectarlas.
Un checklist no es burocracia. Es la diferencia entre operar un SaaS y heredar un bug. Cada ítem de esta lista existe porque un comprador real, en una transacción real, se enteró de él recién en el mes dos, cuando el vendedor ya había cobrado. El objetivo de correrlo antes del cierre no es matar operaciones. Es tasarlas correctamente y caminar de las tres o cuatro de cada cien que están estructuralmente rotas.
A. Producto y tecnología (5 puntos)
1. ¿Cuál es el stack y es un stack que realmente puedes operar?
Pide las versiones exactas del framework, la base de datos, el hosting, la integración de pagos, el proveedor de email y cada API de terceros que toque el flujo de usuario o la facturación. Compáralo contra el stack SaaS moderno por defecto (Next.js o equivalente, Postgres, Vercel o un PaaS, Stripe, Resend o Postmark). Las elecciones exóticas no son banderas rojas automáticas, pero elevan el costo del retainer de mantenimiento, a veces entre 2x y 3x, y ese costo sale de tu margen.
Camina si: el producto depende de un framework o runtime que el desarrollador original dejó de soportar, y no existe una ruta de migración documentada.
2. ¿Dónde está alojado y se pueden transferir las cuentas en serio?
Hosting, base de datos, CDN, monitoreo, logs, email transaccional, registrar del dominio. Cada uno necesita una cuenta con dueño nombrado y un procedimiento de transferencia documentado. Algunos proveedores (Stripe, Google Workspace) tratan la transferencia como un proceso formal con verificaciones de compliance; otros (AWS, Vercel) la permiten con menos fricción. Confírmalo directamente con cada proveedor, no por palabra del vendedor.
Camina si: la base de datos productiva vive bajo la cuenta personal del vendedor sin estructura de organización, y el proveedor no soporta cambio de propiedad no destructivo.
3. ¿El historial de commits cuenta una historia creíble?
Trae el log completo de git. Estás buscando meses —idealmente un año o más— de trabajo distribuido: commits pequeños, mensajes con significado, ramas de bugfix, refactors. Un repositorio con un commit inicial gigante y correcciones esporádicas de typos encima es copy-paste, generación con IA en un fin de semana o una exportación limpia que escondió la historia real. Las tres cosas son problemas que vas a heredar.
Camina si: el historial de commits es más joven que la edad declarada del producto en más de un 30%, y el vendedor no puede producir el repositorio original.
4. ¿Un desarrollador nuevo puede buildear y deployar el proyecto en menos de un día?
Esta es la mejor prueba de calidad de documentación. Contrata un desarrollador (por hora, 150–300 dólares, con 4 horas alcanza) para que clone el repositorio, siga el README, y produzca una instancia local funcionando más un deploy en staging. Si no puede, no compraste un producto: compraste un rompecabezas. En este punto fallan dos tercios de los listings de marketplace.
Camina si: no existe una referencia de variables de entorno, o el deploy depende de pasos manuales no documentados que solo el vendedor conoce.
5. ¿Qué tan viejas son las dependencias y cuántas tienen CVEs críticos abiertos?
Corre npm audit, pip-audit o el equivalente del stack. Un puñado de advertencias de severidad media es normal. Múltiples CVEs críticos sin parchear sobre paquetes core —librerías de auth, runtime del framework, drivers de base de datos— significa que el producto está a un scan automatizado de aparecer en un boletín público de vulnerabilidades. Parchear lleva tiempo; presupuestalo en el precio de la operación.
Camina si: la capa de autenticación o de manejo de pagos tiene un CVE crítico abierto y el vendedor no lo parcheó en 60 días.
B. Finanzas (4 puntos)
6. ¿Cuál es la calidad del MRR, no solo el número?
Pide acceso de solo lectura a Stripe (o el procesador que use) por los últimos 24 meses, más el export completo de suscripciones. La calidad del MRR significa tres cosas: los ingresos son recurrentes (no pagos únicos re-etiquetados como suscripciones), están cobrados (no facturados-pero-impagos) y no están inflados por prepagos anuales contabilizados mensualmente. Compará el número de MRR del procesador contra la línea del P&L del vendedor, renglón por renglón. Según el Biannual Acquisition Multiples Report de Acquire.com (enero 2026, consultado abril 2026), el múltiplo de profit mediano de SaaS cerró en 3,9x en 2024 y 2025, pero ese múltiplo se aplica sobre profit real y verificado, no sobre lo que el vendedor tipeó en una planilla.
Camina si: el vendedor ofrece screenshots en lugar de acceso al procesador, o el MRR en Stripe difiere de lo que el vendedor declara en más de un 10%.
7. ¿Cómo se ve realmente la curva de churn por cohorte mensual?
Un único número de "3% de churn mensual" casi siempre es engañoso. Pide retención por cohorte según mes de alta, sobre al menos 12 meses. Lo que quieres ver es una curva que se aplana: los usuarios que sobreviven los primeros 90 días tienden a quedarse. Lo que no quieres ver es una línea que erosiona constantemente, porque eso significa que el producto pierde incluso a sus usuarios leales con el tiempo. Los benchmarks publicados de ChartMogul (consultado abril 2026) ubican el churn mensual mediano de SaaS SMB por encima del 4%; cualquier número materialmente superior debe tasarse dentro del múltiplo, no pasarse por alto.
Camina si: no existen datos por cohorte y el vendedor no puede reconstruirlos a partir del export de suscripciones.
8. ¿Cuánto es el CAC, cuánto el payback y quién lo está pagando?
El costo de adquisición de clientes es el costo mezclado de marketing y ventas dividido por los nuevos clientes pagos del mismo período. El payback es CAC dividido por el margen bruto mensual por cliente. Si el payback de CAC supera los 18 meses en un producto SMB, el negocio está hambreado de crecimiento: el vendedor lo opera en estado estacionario pero no puede escalarlo sin inyectar capital que tú no tienes. Si el vendedor declara CAC cero porque la adquisición es 100% orgánica, pregunta específicamente quién escribe el contenido, cuántas horas invierte por mes, y si ese trabajo se detiene el día que te entrega las llaves.
Camina si: el vendedor no puede nombrar el mix real de canales con porcentajes, o declara viralidad pura en una categoría donde no existe.
9. ¿Cuál es la concentración de ingresos en los principales clientes?
Exporta la lista completa de clientes ordenada por contribución al MRR. Calcula la participación del top 1, top 3 y top 10. En un micro-SaaS, una concentración del top 3 por encima del 25% es un riesgo estructural: perder uno de esos contratos mueve la valuación un porcentaje material. Las operaciones enterprise se esconden dentro de la etiqueta "SaaS" más seguido de lo que los compradores esperan; revisa duración del contrato, renovación automática y plazo de aviso para cada cliente que supere el 5% del MRR.
Camina si: un único cliente representa más del 20% del MRR y está en términos mes a mes.
C. Clientes (3 puntos)
10. ¿Cuánto soporte genera realmente el producto, por semana?
Pide los últimos 90 días de tickets de soporte: volumen, tiempo mediano de resolución, los cinco problemas recurrentes más frecuentes. La mayoría de los compradores descubre en el mes dos que "5 horas semanales de ops" en realidad significa "5 horas en una semana tranquila". Los problemas recurrentes también son una señal de deuda de producto: si los mismos tres bugs aparecen todas las semanas, compraste un backlog, no un producto estable. Multiplica el volumen de tickets observado por la cantidad de usuarios a la que quieres crecer, y presupuesta el soporte en consecuencia.
Camina si: el mismo bug crítico aparece en tickets por más de 60 días sin que se haya enviado un fix.
11. ¿Por qué cancelan realmente los clientes?
Los motivos de cancelación recolectados en el flujo de baja son oro. Si la razón es "demasiado caro", tienes upside de pricing. Si es "falta la funcionalidad X", tienes un input claro de roadmap. Si es "encontré una alternativa mejor" —y la alternativa se repite— puede que estés comprando un producto a punto de volverse commodity. Si no existe un flujo de motivo de cancelación, eso mismo es un hallazgo: el vendedor no operó el producto como un operador.
Camina si: la razón principal de cancelación es "el producto no funciona de forma confiable" con cualquier volumen por encima de lo anecdótico.
12. ¿Hay alguna señal cualitativa de que los clientes realmente aprecian el producto?
NPS, CSAT, sitios de reviews de producto (G2, Capterra, Product Hunt), testimonios espontáneos, participación del tráfico de referencia. Estás buscando cualquier evidencia independiente de que este producto le importa a sus usuarios. Un SaaS con 3.000 dólares de MRR y doce testimonios sinceros es un activo distinto a un SaaS con 3.000 dólares de MRR y silencio absoluto. El primero tiene defensibilidad; el segundo es una cinta de correr.
Camina si: el producto lleva 18 o más meses en el mercado sin huella pública de reseñas ni NPS de ningún tipo dentro del producto.
D. Legal y propiedad (4 puntos)
13. ¿La cadena de propiedad intelectual está limpia desde el primer commit hasta hoy?
Cada línea de código tiene que estar escrita por el vendedor, por un empleado bajo cláusula de work-for-hire, por un contratista que firmó una cesión de PI, o licenciada bajo una licencia open source compatible con uso comercial. Pide la lista de contratistas, los acuerdos de cesión y una auditoría de licencias de las dependencias. Este es el ítem más pasado por alto en las transacciones de micro-SaaS, y el más caro de arreglar de forma retroactiva.
Camina si: algún contratista que escribió código material no puede ser ubicado para firmar una cesión, o se niega a hacerlo.
14. ¿Las cesiones de contratistas y empleados cubren realmente el trabajo?
Un NDA firmado no es una cesión de PI. Un acuerdo de cesión tiene que nombrar el trabajo, ceder los derechos y estar fechado antes de la entrega. Si el vendedor usó freelancers de Upwork, Fiverr o una agencia regional, los contratos por defecto de esos marketplaces pueden o no incluir cesión: revisa cada uno.
Camina si: el desarrollador principal que escribió más del 30% del código no tiene un acuerdo de cesión en regla.
15. ¿Las marcas, los dominios y los activos de marca están registrados y son transferibles?
El dominio tiene que estar en la cuenta del registrar del vendedor sin un bloqueo que impida la transferencia. La marca, si está registrada, tiene que estar en una jurisdicción que te importe: una marca registrada en Estados Unidos te sirve si planeas vender en Estados Unidos; no te sirve de nada en España o en México. Logos, tipografías y fotografía tienen que estar en propiedad o licenciados para uso comercial, con licencia transferible.
Camina si: el dominio primario está a nombre de un tercero (un ex contratista, un socio caído, la ex pareja del vendedor: todos casos reales).
16. ¿Dónde viven los datos de los clientes y eso coincide con dónde están esos clientes?
GDPR, CCPA, LGPD y equivalentes convierten la residencia de datos en un término material, no en un detalle burocrático. Si el producto sirve a clientes de la UE y la base de datos vive en una región solo-US, estás heredando un gap de compliance que cuesta dinero real arreglar. Pide la política de privacidad, el DPA con cada subprocesador, y la región geográfica real de cada almacén de datos.
Camina si: el producto procesa datos personales de la UE y no tiene DPA con su proveedor de hosting, o no tiene política de privacidad en absoluto.
E. Operaciones (4 puntos)
17. ¿Existe un runbook escrito para cada tarea operativa recurrente?
Onboarding de usuario, procesamiento de reembolsos, cambios de plan, recuperación de pagos fallidos, cancelación de suscripción, respuesta a incidentes, revisión semanal de métricas. Un runbook es un documento paso a paso que un operador nuevo puede seguir sin preguntarle al vendedor. Si no existe ninguno, el vendedor es el runbook, y el vendedor se va en 30 días. Espera construirlos tú después del cierre, y presupuesta entre 40 y 80 horas de tiempo de transición documentado con el vendedor.
Camina si: el vendedor no puede producir un solo runbook escrito y describe las operaciones como "yo simplemente sé cómo hacerlo".
18. ¿Cuál es la lista completa de proveedores, con costo mensual por cada línea?
Hosting, base de datos, CDN, monitoreo, logs, email, pagos, analytics, seguimiento de errores, herramienta de soporte, APIs de IA/ML, cualquier otra cosa. Cada proveedor, cada factura mensual, cada término de contrato. Suma todo contra la línea de "infraestructura" del P&L del vendedor. Los desajustes entre la lista de proveedores y el P&L son la fuente más común de unit economics reformulados, como la escena con la que abre este post.
Camina si: cualquier línea individual de proveedor supera el 15% de los ingresos brutos y no aparece como costo material en el P&L.
19. ¿Hay SLAs con clientes y puedes cumplirlos en serio?
Si el producto vende a B2B con SLAs escritos (compromisos de uptime, garantías de tiempo de respuesta, derechos de exportación de datos), lee cada uno. Los SLAs no desaparecen porque la empresa cambia de manos: se transfieren. Un SLA del 99,9% de uptime sobre infraestructura de una sola región sin failover es un pasivo que no viste hasta la primera caída.
Camina si: existe cualquier SLA que la infraestructura actual no puede cumplir de forma demostrable, y no hay plan para cerrar el gap.
20. ¿Se corrió alguna vez un simulacro de backup y restore, de punta a punta?
Tener backups diarios en un dashboard no es lo mismo que un restore verificado. Pide al vendedor que demuestre un restore del backup de ayer a un ambiente de staging, en vivo, contigo mirando. Si no puede o no quiere, los backups son teóricos y el plan de recuperación ante desastres es ficción. Es una prueba de 90 minutos que evita un problema de cinco cifras.
Camina si: nunca se probó un restore, y el vendedor se niega a correr uno antes del cierre.
F. Canales de crecimiento (4 puntos)
21. ¿De dónde viene realmente el tráfico, mes a mes?
Pide 24 meses de desglose de fuentes de tráfico en la plataforma de analytics: no un screenshot, un acceso de solo lectura. Búsqueda orgánica, directo, referidos, pago, social, email. Lo que quieres ver es diversificación y estabilidad. Lo peligroso es una única fuente por encima del 70%, porque esa fuente está a un cambio de algoritmo o una suspensión de cuenta de llegar a cero.
Camina si: más del 70% de las altas viene de un único canal que el comprador no puede influir directamente.
22. Si el SEO es el foso, ¿es un foso real?
Trae las 50 palabras clave con mejor ranking, sus posiciones, sus volúmenes de búsqueda y las páginas que rankean. Revisa el perfil de backlinks y la autoridad de dominio en una herramienta como Ahrefs o Semrush. Un foso de SEO es real cuando múltiples keywords de alto volumen rankean en primera página, con backlinks ganados desde dominios no spam, y las páginas que rankean son contenido genuino escrito por un humano. Un foso de SEO es falso cuando los rankings dependen de una única página programática, una red de enlaces comprada, o stuffing de keywords que Google eventualmente va a demoler.
Camina si: el perfil de backlinks está dominado por fuentes PBN obvias, o el tráfico se concentra en keywords que ya muestran líneas de tendencia a la baja.
23. Si la adquisición paga es un canal, ¿la atribución está realmente medida?
"Gastamos 4.000 dólares por mes en ads y funciona" no es atribución. Pide acceso a la cuenta de la plataforma de ads, los eventos de conversión y el CAC por canal de los últimos 12 meses. Sin atribución adecuada, el vendedor no puede probar que los 4.000 funcionan, y tú tampoco vas a poder probarlo después del cierre, cuando estés gastándolos.
Camina si: el gasto pagado supera los 1.000 dólares mensuales y el seguimiento de conversiones no está configurado, o está mal configurado.
24. ¿Qué activos de contenido vienen con el producto y quién los escribió?
Posts de blog, landing pages, secuencias de email, flujos de onboarding, documentación de ayuda, cuentas sociales, videos de YouTube, participaciones en podcasts. Cada uno es un activo. Cada uno tiene un autor. Cada uno necesita una licencia o cesión si no fue escrito personalmente por el vendedor. El contenido ghostwritten está bien; el contenido ghostwritten sin licencia es una demanda esperando pasar.
Camina si: más del 30% del corpus de contenido fue producido por un contratista sin acuerdo de cesión en regla.
G. Vendedor y traspaso (3 puntos)
25. ¿Por qué vende realmente el vendedor?
El motivo declarado y el motivo real suelen ser distintos. Razones legítimas comunes: rotación de portfolio (está construyendo la próxima cosa), restricciones de ancho de banda por manejar varios productos, desajuste de estilo de vida, un fundador que está genuinamente cansado. Razones preocupantes comunes: el lanzamiento inminente de un competidor que el vendedor conoce, un cliente clave amenazando con irse, una dependencia a punto de volverse cara. Triangula preguntándole al vendedor directamente, revisando el registro público, y hablando con un cliente actual con permiso del vendedor.
Camina si: la razón declarada contradice lo que muestran los números, o el vendedor se niega a que hables con un solo cliente antes del cierre.
26. ¿Qué incluye realmente el período de entrenamiento y por cuánto tiempo?
"Soporte post-venta" en un listing de marketplace suele significar dos horas de Zoom. Defínelo por escrito: horas por semana, duración en semanas, canales (Slack, email, llamada), expectativa de tiempo de respuesta, alcance de preguntas cubiertas, y qué pasa si algo se rompe en el mes dos. Menos de 30 días es casi siempre insuficiente para un comprador no técnico que se hace cargo de un producto real.
Camina si: la transición ofrecida por el vendedor es menor a dos semanas y se niega a extenderla a cualquier precio.
27. ¿Qué cubre realmente el no-compete y es ejecutable?
El no-compete tiene que nombrar la categoría del producto, la geografía y la duración. Un no-compete mundial a 5 años probablemente sea inejecutable y cualquier corte lo va a tumbar. Un no-compete de 18 a 24 meses en el vertical específico es defendible y genuinamente protector. Igual de importante: una cláusula de no-solicitación que cubra la lista de clientes y cualquier empleado o contratista.
Camina si: el vendedor se niega a firmar cualquier no-compete, o ya registró dominios en la misma categoría.
Cómo secuenciar los 27 puntos
Correr los 27 en paralelo es una forma de quemar 40 horas en una operación que nunca iba a cerrar. Secuéncialos.
Fase 1 — Filtro pre-LOI (puntos 1, 3, 6, 9, 13, 18, 21, 25). Estas son las ocho preguntas que puedes responder con información pública, una llamada de 60 minutos con el vendedor y un vistazo limitado al data room. Si alguna vuelve mal, te ahorraste las tres semanas de exclusividad. Este es el modo de falla más barato que tienes.
Fase 2 — Análisis profundo post-LOI (puntos 2, 4, 5, 7, 8, 10, 11, 12, 14, 15, 16, 17, 19, 22, 23, 24). Requieren acceso completo al data room, tiempo pago de asesores y pruebas concretas (el deploy de un día, el export de cohortes, las llamadas de confirmación a proveedores). Presupuesta 2 a 3 semanas. Aquí es donde reconfirmas el precio o lo renegocias contra lo que dicen los datos.
Fase 3 — Verificación pre-cierre (puntos 20, 26, 27). El simulacro de restore, el alcance escrito del entrenamiento, el texto del no-compete. Se hacen en la última semana antes de firmar. Son baratos de correr pero caros de omitir: son los ítems que importan en el mes dos, no en el mes uno.
Una operación que pasa la Fase 1 pero muere en la Fase 2 costó 500 dólares de tiempo legal y una semana de calendario. Una operación que pasa la Fase 3 está lista para cerrar.
Dónde se rompe esto en los marketplaces
En Flippa y Acquire.com, el comprador corre este checklist solo. No hay un traspaso estándar. No hay nadie que garantice que los runbooks existen, que el período de entrenamiento es real, o que el simulacro de restore se va a demostrar antes del cierre. La motivación del vendedor, por definición, es seguir adelante. La motivación del comprador es evitar sorpresas en el mes dos. Esas dos motivaciones no están alineadas, y el checklist existe precisamente por ese gap.
The Ownix funciona distinto porque la premisa inicial es distinta. Cada producto en el portfolio se entrega con runbooks pre-construidos, una lista documentada de proveedores con costos mensuales, SLAs calibrados a la infraestructura efectivamente provisionada, y una ventana de 30 días de soporte operativo, de modo que los puntos E1–E4 y G2 de esta lista vienen pre-respondidos en la entrega, no se negocian operación por operación. Eso no vuelve irrelevantes a los 22 puntos restantes: calidad de producto, canales de crecimiento, cadena legal, registros de marca siguen importando, y esperamos que el comprador los pregunte. Sí significa que los cinco ítems más frágiles operativamente no son donde está la fricción. Es una decisión deliberada sobre qué tipo de transacción es esta.
Apéndice imprimible: las 27 preguntas
A. Producto y tecnología
- ¿Cuál es el stack y es un stack que realmente puedes operar?
- ¿Dónde está alojado y se pueden transferir las cuentas en serio?
- ¿El historial de commits cuenta una historia creíble?
- ¿Un desarrollador nuevo puede buildear y deployar el proyecto en menos de un día?
- ¿Qué tan viejas son las dependencias y cuántas tienen CVEs críticos abiertos?
B. Finanzas 6. ¿Cuál es la calidad del MRR, no solo el número? 7. ¿Cómo se ve realmente la curva de churn por cohorte mensual? 8. ¿Cuánto es el CAC, cuánto el payback y quién lo está pagando? 9. ¿Cuál es la concentración de ingresos en los principales clientes?
C. Clientes 10. ¿Cuánto soporte genera realmente el producto, por semana? 11. ¿Por qué cancelan realmente los clientes? 12. ¿Hay alguna señal cualitativa de que los clientes realmente aprecian el producto?
D. Legal y propiedad 13. ¿La cadena de propiedad intelectual está limpia desde el primer commit hasta hoy? 14. ¿Las cesiones de contratistas y empleados cubren realmente el trabajo? 15. ¿Las marcas, los dominios y los activos de marca están registrados y son transferibles? 16. ¿Dónde viven los datos de los clientes y eso coincide con dónde están esos clientes?
E. Operaciones 17. ¿Existe un runbook escrito para cada tarea operativa recurrente? 18. ¿Cuál es la lista completa de proveedores, con costo mensual por cada línea? 19. ¿Hay SLAs con clientes y puedes cumplirlos en serio? 20. ¿Se corrió alguna vez un simulacro de backup y restore, de punta a punta?
F. Canales de crecimiento 21. ¿De dónde viene realmente el tráfico, mes a mes? 22. Si el SEO es el foso, ¿es un foso real? 23. Si la adquisición paga es un canal, ¿la atribución está realmente medida? 24. ¿Qué activos de contenido vienen con el producto y quién los escribió?
G. Vendedor y traspaso 25. ¿Por qué vende realmente el vendedor? 26. ¿Qué incluye realmente el período de entrenamiento y por cuánto tiempo? 27. ¿Qué cubre realmente el no-compete y es ejecutable?
Conclusión
La due diligence no es defensiva. Es pricing. Cada pregunta de la lista confirma la narrativa del vendedor, revela una palanca para renegociar, o expone la razón para caminar. Los cinco ítems de "caminá si" —uno por categoría entre los más estructurales— te protegen de las operaciones que parecen bien en la superficie y están rotas por debajo. Los 22 restantes son cómo llegas a un número que refleja el activo que estás comprando realmente, no el pitch.
Si estás corriendo esta lista contra un listing de marketplace, córrela solo y córrela en secuencia. Si quieres un punto de partida donde los ítems más frágiles operativamente ya vienen resueltos —runbooks, claridad de proveedores, período de entrenamiento, garantía— mira el catálogo de startups, revisa los modelos de compra directa y licencia territorial, o compáralos con pricing por modelo.
Comprar un SaaS bien no es encontrar el activo perfecto. Es tasar con precisión lo que estás comprando y negarte a cerrar sobre lo que está estructuralmente roto. Veintisiete preguntas son la forma más barata de hacer las dos cosas.
---META---
Meta description (150–160 chars): Checklist de due diligence SaaS de 27 puntos: producto, finanzas, clientes, legal, operaciones, crecimiento y traspaso. Cinco motivos para caminar, 22 palancas de precio.
OG title: Due diligence antes de comprar un SaaS: el checklist de 27 puntos
OG description: Veintisiete preguntas, siete categorías, tres fases. El checklist que usan los compradores para tasar lo que están comprando realmente y caminar de lo que está roto.
Twitter title: El checklist de 27 puntos para comprar un SaaS
A/B headlines (4 variantes):
- Due diligence antes de comprar un SaaS: el checklist de 27 puntos
- Checklist de adquisición de SaaS: 27 preguntas y cinco motivos para caminar
- Cómo auditar un SaaS antes de comprarlo: un marco de 27 puntos
- Compra un micro-SaaS sin heredar un bug: el checklist de 27 puntos
Fuentes citadas:
- Acquire.com, Biannual Acquisition Multiples Report (enero 2026, consultado abril 2026) — múltiplos de profit en SaaS.
- Flippa, Online Business M&A Insights 2025 Recap & 2026 Outlook (diciembre 2025, consultado abril 2026) — datos de marketplace referenciados vía la guía pilar.
- ChartMogul, benchmarks publicados de retención y churn en SaaS (consultado abril 2026) — referencia de churn mensual mediano en SMB.
Enlaces internos incluidos:
/es/blog/comprar-startup-2026-guia-completa(enlace pilar en "Por qué 27 puntos")/es/portfolio(sección de marketplaces + conclusión)/es/comprar-startup(conclusión)/es/pricing(conclusión)
¿Listo para ver las startups disponibles?
Explora el portafolio de startups construidas y listas para operar.