Comprar, construir o conectar: qué SaaS sí dejar de pagar

En octubre de 2026 leí en LinkedIn el post de un director de una empresa española. Contaba que dejó de pagar una herramienta porque la construyó con IA, y lo resumía así: lo que sustituyó era una capa encima de sus datos; lo que sigue pagando es donde viven los datos. Tiene razón. A nosotros, en SCRAM Consulting, nos pasó lo mismo durante 2026, con una diferencia que ese post no contaba.

Construimos nuestro propio motor de correo dentro del CRM y dejamos de pagar la herramienta de automatización que usábamos. Pero seguimos pagando a quien entrega los correos y a quien verifica los buzones. Esa diferencia es la que te quiero explicar, porque es la que decide qué SaaS sí puedes dejar de pagar.

Resumen ejecutivo

• No todos los SaaS son iguales: unos son una capa encima de tus datos y otros son el lugar donde viven tus datos.
• La capa se puede reemplazar o construir; el sistema de registro casi nunca conviene reemplazarlo.
• Hay una tercera opción que casi siempre gana: conectar lo que ya tienes y construir solo la pieza que te diferencia.
• Lo que parece fácil de clonar suele tener una parte operativa que no se clona: en el correo, la entrega.
• Antes de cancelar un SaaS, contesta las siete preguntas de la checklist de este artículo.

¿Qué SaaS sí conviene dejar de pagar?

El que solo es una pantalla encima de datos que viven en otro sistema. Si la herramienta lee de tu ERP, te muestra algo y escribe de regreso, es una capa. Si te cobra por usuario y la usas para una tarea acotada, construirla o integrarla a lo que ya tienes puede salir mejor. El que guarda tu historial fiscal, contable o de inventario, no.

La razón es la gravedad de los datos. Cuanto más historial, integraciones, auditorías y personas entrenadas tiene un sistema, más cuesta moverlo. Una pantalla de reportes no tiene casi nada de eso. Tu ERP tiene todo.

¿Qué hicimos nosotros con nuestro ERP?

Dejamos a Bind ERP como fuente de verdad y construimos encima la capa que nos faltaba. Las cotizaciones, los pedidos y las facturas se hacen en Bind, y nuestro ERP y CRM los traen en automático. La dirección consulta ventas, cobranza y seguimientos en nuestra capa; el dato fiscal se queda donde está.

No fue una preferencia ideológica. La API de Bind no permite crear cotizaciones desde fuera, así que Bind manda y nuestro sistema refleja. Esa restricción nos obligó a hacer lo correcto: no duplicar la fuente de verdad. Ya lo contamos en cómo cada cotización de Bind se volvió un seguimiento en el CRM.

Mi postura: si tu ERP cumple con lo fiscal y tu equipo lo conoce, no lo cambies por uno nuevo. Construye la capa que le falta.

¿Y el correo? Lo construimos, pero compramos la entrega

Construir un motor de correo es la parte fácil: segmentos, flujos, plantillas y un tablero de aperturas. Lo difícil es que el correo llegue. Eso depende de la reputación del dominio, del manejo de rebotes y quejas y de las reglas de Gmail y Yahoo. Por eso seguimos pagando un proveedor de envío y un servicio de verificación.

Lo aprendimos con números. En agosto de 2026 nuestro sistema registró cero rebotes en 406 correos. No era buena entregabilidad: el sistema no estaba recibiendo la señal de rebote. Lo corregimos el 26 de agosto. Después, al calentar una lista fría, el rebote duro llegó a 11.3%. Verificamos los buzones antes del siguiente envío y la serie de octubre rebotó 1.0%: dos de doscientos.

Las reglas de la entrega no las pones tú. Desde febrero de 2024, Gmail exige a quien manda más de 5,000 correos diarios autenticar el dominio con SPF, DKIM y DMARC, ofrecer baja con un clic y mantener la tasa de spam reportada por debajo de 0.3%. Cumplir eso no es pintar una pantalla; es operación de todos los días. La historia completa del freno que pusimos está en por qué tu correo masivo debe pausarse solo.

¿Comprar, construir o conectar?

Compra lo regulado, lo que tiene efecto de red y lo que usas poco. Construye la capa que te diferencia y que nadie vende a tu medida. Conecta todo lo demás: deja el sistema de registro donde está y programa solo el puente. En nuestra experiencia, conectar es la respuesta más frecuente.

Tipo de herramienta	Ejemplo en SCRAM Consulting	Decisión	Por qué
Sistema de registro fiscal y documental	Bind ERP	Comprar y conservar	Ahí viven las facturas, los folios y el historial; cambiarlo es caro y riesgoso
Capa de consulta y seguimiento	Nuestro ERP y CRM	Construir y conectar	Es como trabajamos nosotros; ningún producto lo traía así
Automatización de marketing	Motor de correo dentro del CRM	Construir	Segmentos y flujos sobre nuestros propios datos de clientes
Entrega de correo	Proveedor de envío	Comprar	La reputación y las reglas de Gmail y Yahoo son operación, no código
Verificación de buzones	Servicio de verificación	Comprar	Bajó nuestro rebote de 11.3% a 1.0%; construirlo no tiene sentido
Timbrado de facturas	Proveedor autorizado por el SAT	Comprar	Es regulado; no se construye

Si quieres el marco general, con ejemplos fuera de nuestra casa, está en ¿comprar o construir software?. Este artículo agrega la tercera vía y el criterio de dónde viven los datos.

¿Qué preguntar antes de cancelar un SaaS?

Siete preguntas. Si contestas "sí" a las tres primeras y tienes quién responda la quinta, la herramienta es candidata a reemplazo. Si alguna de las tres primeras es "no", probablemente es un sistema de registro y conviene conservarlo o conectarlo.

1. ¿Los datos que muestra viven en otro sistema que ya pagas?
2. ¿Puedes sacar tus datos completos, con historial, en un formato que otro sistema lea?
3. ¿Lo que hace la herramienta es algo propio de tu operación, no algo regulado ni fiscal?
4. ¿Cuánto pagas al año contra cuántas horas al mes costaría mantener lo construido?
5. ¿Quién lo va a mantener cuando cambie la API del sistema de origen, y quién lo cubre si esa persona se va?
6. ¿Qué parte operativa no se ve en la pantalla? En el correo es la entrega; en pagos, el cumplimiento; en soporte, la guardia.
7. ¿Puedes probar en paralelo dos o tres semanas antes de cancelar?

La quinta pregunta es la que más se salta y la que más cuesta. Le dedicamos un artículo completo: quién mantiene lo que construiste.

¿Dónde se equivoca la gente al decidir?

En comparar el precio de la suscripción contra el costo de construir solo el primer mes. La suscripción incluye mantenimiento, seguridad, soporte y cambios de versión. Lo construido también los necesita, y los pagas tú. La comparación honesta es a tres años, con las horas de quien lo mantiene adentro.

El otro error es creer que porque la IA escribe código rápido, construir ya cuesta poco. Escribir la primera versión sí cuesta menos. Revisarla, probarla y mantenerla cuesta lo mismo que antes. En SCRAM usamos IA todos los días para programar, y por eso lo decimos: la velocidad sin pruebas solo te lleva más rápido a un sistema que nadie entiende.

Si estás pensando qué herramientas dejar de pagar, agenda un diagnóstico de tus sistemas: revisamos contigo qué es capa y qué es registro, y te decimos qué conviene conectar primero. Para entender cómo trabajamos una capa propia de principio a fin, lee cómo implementamos un Sistema Vivo en dos semanas y la guía completa de software a la medida.

Ing. Armando Cortés