- Aunque era escéptico ante la idea de que los SaaS serían reemplazados por LLM, comparte la experiencia de haber sustituido en solo 20 minutos con código propio un servicio de visualización de testimonios de LinkedIn/X que costaba 120 dólares al año
- El servicio reemplazado tenía el sistema de pagos roto desde 2023 y el soporte al cliente solo respondió con un enlace dañado
- Usando Codex, convirtió el sistema a un enfoque modular en el que los testimonios se separan en archivos JSON y se genera HTML en tiempo de compilación, con un resultado visual idéntico al original
- Para desarrolladores es una tarea rápida e interesante, pero para quienes no programan, validar el código generado por un LLM puede ser una barrera de entrada
- Los micro SaaS estáticos que no aportan valor continuo son los que más riesgo tienen de ser reemplazados primero en la era de los LLM
Escepticismo previo sobre la teoría de que los LLM reemplazarán a los SaaS
- La idea central de esta teoría: los SaaS son productos de software puro, y como los LLM reducen drásticamente el costo y el tiempo de crear software a medida, la mayoría de los proveedores SaaS desaparecerán
- Como contraargumento, software de RR. HH. como Workday no es solo software: también garantiza el cumplimiento normativo en distintos países (vacaciones pagadas, recibos de sueldo, etc.) y se actualiza continuamente según los cambios del entorno interno y externo
Experiencia con Shoutout.io y motivo para abandonarlo
- Usó Shoutout.io durante 4 años por 120 dólares anuales para mostrar una sección de testimonios basada en publicaciones de LinkedIn y X en pragmaticengineer.com
- Solo iniciaba sesión una vez al año aproximadamente, y la última vez fue para revisar la factura anual con fines de gastos
- La sección de pagos llevaba rota desde 2023, y aunque escribió al equipo de soporte, recibió de vuelta un enlace roto
- El hecho de no poder confirmar siquiera cuánto costaría el servicio el año siguiente fue el detonante directo para dejar ese SaaS
Reemplazo en 20 minutos usando Codex
- En vez de reconstruir todo el SaaS, el enfoque fue rehacer solo su caso de uso concreto: mostrar testimonios, añadir nuevos testimonios y mantener el diseño
- Le pidió a Codex que planificara cómo eliminar la dependencia de terceros y alojarlo dentro del repositorio de GitHub
- Ajustó el sistema a un enfoque modular en el que los testimonios se gestionan en archivos JSON separados y se convierten en HTML durante la fase de build en tiempo de compilación
- Entre agregar el paso de build local, configurar el disparador de build de Netlify, probar, ajustar la UX, generar el esquema y desplegar, el trabajo total tomó 20 minutos
- El resultado final es visualmente idéntico al original y elimina por completo la dependencia de terceros
- Cuando el equipo de soporte finalmente envió un enlace correcto (dos horas después), la migración ya estaba terminada
Implicaciones para los ingenieros de software
- Los desarrolladores ya están más habituados a usar la línea de comandos y agentes de IA para insertar testimonios en una base de código y verificar el resultado, pero para quienes no programan, validar la salida de código de un LLM sigue siendo una barrera de entrada
- La velocidad con la que un desarrollador puede "portar" un SaaS a código propio es mucho mayor que la de una persona no técnica
- En el primer intento, Codex lo implementó incorrectamente con un modelo flexbox, y hubo que decidir manualmente el framework de layout de la UI
- Una persona no técnica también podría resolverlo, pero probablemente tardaría más
- Reescribir por cuenta propia una función de terceros es una tarea divertida y con valor de aprendizaje, además de una oportunidad para experimentar el rendimiento real de estas herramientas
Implicaciones para el negocio SaaS
- Reconstruir un SaaS completo y reconstruir solo un caso de uso específico son cosas muy distintas en nivel de dificultad
- Shoutout tiene más de 10 veces más funcionalidades, como agregar citas desde más de 10 plataformas, autenticación y pagos
- Los SaaS estáticos que no aportan valor continuo después de mostrar testimonios son los más fáciles de reemplazar
- En cambio, si ofrecen funciones de soporte al negocio en tiempo real como cumplimiento, analítica o alertas, reemplazarlos es mucho más difícil
- Posible caída de la rentabilidad del negocio de compra y venta de SaaS
- Shoutout fue creado por un desarrollador independiente en 2020, vendido a un estudio de producto en 2022 y revendido a otro desarrollador en 2025
- Desde la perspectiva del usuario, no hubo cambios aparte del sistema de pagos roto
- Es posible que los compradores esperaran crecer los ingresos sin invertir, pero si el producto se abandona, los usuarios se van y llega el momento en que puede ser reemplazado fácilmente con LLM
- Vivimos en una época en la que dejar pasar las "ventanas rotas (Broken Windows)" es mucho menos tolerable que antes
4 comentarios
El costo de mantenimiento también cuesta
La adopción de software siempre debe evaluarse desde la perspectiva del
TCOa lo largo de “5 años”. Si no, al final lo único que haces es acumular “bombas” que de verdad van a explotar más adelante.Parece que de verdad lo pensó de una forma demasiado simple jajaja
¿Lo escribió alguien que trabaja para la empresa? Porque una vez que lo construyes tú mismo, en adelante habrá que gestionar para que esa función siga operando internamente en vez de con un proveedor externo; ¿y eso se supone que es gratis, sin costo de tiempo ni de dinero?