- Se dice que la integración de SaaS permite a los desarrolladores enfocarse solo en el producto, pero en la práctica siempre existen 5 costos ocultos (impuestos)
- Antes de adoptarlo, en cada etapa de descubrimiento, registro, integración, desarrollo local y operación siguen apareciendo tiempo, complejidad y carga mental
- Si en vez de SaaS eliges una plataforma integrada (Cloudflare, Supabase, etc.), puedes reducir mucho estos costos y complejidades repetitivas
- Como el vendor lock-in es una realidad inevitable, en lugar de mezclar varios servicios, lo mejor es mantener el flujo de desarrollo (Flow) dentro de una sola plataforma integrada
- Al final, lo más importante no es el framework o el servicio en sí, sino el software que quiero construir
SaaS es solo vendor lock-in con mejor branding
- A los desarrolladores se les dice “concéntrate solo en construir el producto”, pero en la práctica adoptar proveedores SaaS para auth, colas, almacenamiento de archivos u optimización de imágenes trae varias cargas adicionales
- No solo hay costo monetario, también existen consumo de tiempo, fricción y cansancio mental.
1. Impuesto de descubrimiento (Discovery Tax)
- Antes de adoptar un servicio SaaS, hay que entender qué función y valor vende realmente
- Hay que evaluar detalles como el alcance de resolución del problema, la compatibilidad con el stack existente, un precio razonable según la escala, la claridad de la documentación y posibles formas peculiares de implementación
- Este proceso de investigación no se comparte ni se reutiliza fácilmente a partir de experiencias previas, y en gran parte depende de decisiones subjetivas
- También recae en uno mismo la carga de juzgar si el mensaje de marketing encaja contigo y si el servicio realmente te ayudará
2. Impuesto de registro (Sign-Up Tax)
- Después de elegir un servicio, hay que entregar correo electrónico y datos de tarjeta
- Es necesario revisar si permite cobro por uso o si solo ofrece lock-in mediante suscripción
- También es problemático que la estructura de precios sea poco transparente, por ejemplo cuando se generan costos extra para que miembros del equipo accedan al dashboard
- Hay que comprobar si se puede probar sin una prueba gratuita formal o si exigen pago desde el inicio
- Incluso antes de escribir una sola línea de código, ya se establece una relación contractual con el proveedor
3. Impuesto de integración (Integration Tax)
- En la adopción real son inevitables tareas como revisar documentación, instalar librerías, conectar el framework y resolver problemas adicionales fuera de la documentación
- A menudo aparecen conflictos con herramientas o problemas inesperados
- Cuando el SaaS solo apunta al mínimo común denominador, se requiere todavía más trabajo en stacks modernos o entornos especializados
4. Impuesto del desarrollo local (Local Development Tax)
- No siempre está claro si el servicio SaaS soporta un entorno local
- Hace falta que ofrezca emuladores locales o que permita usar stubs con fines de prueba
- Para verificar algunas funciones, a veces se requiere tunneling hacia la nube, lo que complica la configuración del entorno
- La separación de configuración entre producción, staging y local termina siendo inevitable
5. Impuesto de producción (Production Tax)
- Tras integrar el servicio, aparecen nuevas cargas en el entorno de producción
- Se necesita gestión adicional para su uso también en staging y entornos de vista previa de PR, así como administración de API keys, monitoreo, logging y alertas
- Hay que prepararse para errores o inconsistencias que no aparecen en desarrollo, pero sí en operación real
- La responsabilidad de mantener la estabilidad del servicio termina recayendo en el desarrollador
Conclusión
- El eslogan del SaaS moderno es “no reinventes la rueda”, pero cada servicio adicional trae fricción
- Adoptar un servicio no es una simple integración sino un contrato, y eso implica más dependencias y cambios en la arquitectura. El vendor lock-in es inevitable, y reemplazar el servicio suele exigir una reescritura considerable de código.
- Por eso, en lugar de repetir este tipo de decisiones, resulta más eficiente elegir desde el principio una plataforma todo en uno
- Lo importante es el software que el desarrollador realmente quiere construir
- Plataformas integradas como Cloudflare y Supabase ofrecen base de datos, colas, imágenes y storage en el mismo entorno, reduciendo de forma importante la carga de esos impuestos mencionados arriba.
- No hace falta cambiar de contexto entre varios proveedores
- Disminuye la frecuencia de problemas al manipular API keys
- Se minimiza la necesidad de gestionar compatibilidad y bifurcaciones por entorno
- Ofrecen una experiencia de integración consistente entre desarrollo y producción
- Estas plataformas dan la sensación de que todo corre en la misma máquina y minimizan la distancia entre el código y los servicios, lo que permite recuperar la inmersión en el desarrollo ("Flow") que ningún SaaS puede ofrecer.
> Lo importante no es elegir un framework o servicio, sino proteger el software que quiero construir y el flujo (Flow)
2 comentarios
Se está poniendo a Supabase como un buen ejemplo, pero entonces, ¿qué servicios SaaS serían los que habría que evitar?
Opinión de Hacker News
Esto lo ve como una versión moderna y enormemente ampliada del “rent seeking” de Adam Smith
Cree que este tipo de actividad económica es socialmente dañina, por lo que debería evitarse e incluso criminalizarse
Por otro lado, el extremo del software libre también es problemático en términos económicos, porque el esfuerzo del creador del software no guarda proporción con el valor que obtiene el usuario
Sostiene que la compra del software y el contrato de servicios deberían manejarse por separado, ya que cada uno aporta un valor distinto en la práctica
El problema en SaaS es que todo eso queda empaquetado en una sola cosa y, en la práctica, el empaquetado termina deformándose de manera excesiva frente al servicio en sí
Si uno siente tanta pasión por esto, entonces debería construir su propio SaaS y montar una empresa que lo despliegue y opere on-premise, ofreciéndolo a precios similares a los del SaaS actual
Dice que si las empresas pudieran conservar el control de sus datos, evitar el vendor lock-in y aun así recibir la misma calidad, garantías y precio que con SaaS, podrían dominar el mercado
Siempre termino dándole vueltas a esto: ¿no bastaría con entregar solo el binario y dejar que el usuario lo ejecute en AWS, GCP o Cloudflare Workers?
Desde mi punto de vista, el saas es atractivo como desarrollador, pero no me gusta como consumidor, así que termino en un dilema ético
Si yo vendiera software, ¿qué haría si el usuario simplemente lo redistribuye sin autorización? No podría controlar la distribución como sí pasa con el SaaS
Soy partidario del foss (código abierto), pero como dices, ese modelo también tiene problemas económicos
También he pensado en cosas como emitir licencias vía GitHub Sponsors, y en algunos proyectos considerar un modelo donde la licencia sea SSPL para autenticación, o cambiar a BSD/MIT al comprar una licencia (similar al Redis de antes)
Aun así, dudo que la gente realmente pague si aplico este modelo, y también estoy considerando ofrecer ambos enfoques, pero no tengo una respuesta clara, así que pido consejo
Como referencia, algunos proyectos que hice incluyen una herramienta para que cualquiera cree criptomonedas gratis, una función para traer un blog desde YouTube, y un almacenamiento ilimitado usando la comunidad y los videos de YouTube como reemplazo de Google Photos, además de que también estoy pensando en mejoras de privacidad. Si tienen ideas de monetización, me gustaría escucharlas
Señala que, para la mayoría de los SaaS, del lado del proveedor existen costos continuos de hosting, soporte, I+D, etc.
Por eso le cuesta empatizar con la lógica de por qué esta estructura sería “rent seeking”
No todo SaaS puede verse como rent seeking, y señala que la “stickiness” del software en sí se parece por naturaleza al rent-seeking
La mayoría de las empresas SaaS buscan stickiness, pero esa no es una propiedad exclusiva del SaaS
Yo vendo mi producto SaaS a clientes que quieren comprarlo a un precio razonable en el mercado
El vendor lock-in normalmente se siente cuando dentro de la empresa alguien pregunta “¿por qué no adoptamos la herramienta NEWTHING?” y la respuesta es que ya están atados por un contrato de 5 años con Oracle, MS, IBM o Salesforce, así que no hay mucho que hacer
Entonces, después de unos 10 años, realmente terminas completamente amarrado a ese proveedor, en una estructura donde ya no puedes cambiar
Si un negocio logra durar 10 años, eso puede ser más bien una bendición o un problema aburrido, pero mi consejo sería que al inicio de una startup no pierdas tiempo eligiendo muchas herramientas y que elijas rápido una sola plataforma para enfocarte
Incluso en esos casos, está la postura de que conviene abstraer los servicios detrás de interfaces estandarizadas
Si haces esa abstracción, después, al cambiar a otro servicio, basta con ofrecer una implementación alternativa
Señala que este enfoque es orientado al futuro, pero que hoy muchas empresas no están preparadas para ello
Creo que minimizar dependencias es uno de los factores más importantes para mejorar la sostenibilidad del producto y del negocio
En mi trabajo anterior me encargué de integrar en nuestro producto una experiencia de firma electrónica estilo DocuSign
Hablamos con proveedores importantes como DocuSign y Adobe, pero sentí que, por las muchas limitaciones de sus APIs, no encajaban bien con las necesidades del producto y de los clientes, así que al final decidimos implementarlo internamente
Normalmente construir algo como DocuSign por cuenta propia sería una mala idea, pero como nuestro producto ya contaba con la confianza de los clientes, la barrera de adopción era baja
Al implementarlo nosotros mismos, al principio hubo mucho trabajo, pero cuando de verdad hacía falta hacer pequeños ajustes personalizados para clientes, pudimos responder rápido, y quedó claro que si hubiéramos usado un proveedor habría sido una obra mucho más engorrosa; por eso fue correcta la decisión de hacerlo internamente
Entiendo que el autor sostiene que no deberíamos comprar SaaS porque es vendor lock-in
Pero en el texto termina recomendando ir all-in con una plataforma específica como Cloudflare
Al final, cualquier elección implica lock-in, e incluso con código abierto o self-hosting, si quieres reemplazarlo, terminas reescribiendo un montón de código
Usar funciones dependientes de un proveedor no es lo mismo que “lock-in real”; el lock-in aparece cuando cambiar cuesta más tiempo y dinero que seguir con lo actual
Si haces el software de manera poco acoplada y con buena cohesión, es más fácil reemplazar partes concretas
Porque si la interfaz es simple, reemplazarla también es simple
Por eso, la decisión de “como todo es lock-in, mejor me ato todavía más fuerte a una sola plataforma” puede ser cómoda para un desarrollador, pero es una mala estrategia desde el punto de vista gerencial, y hay que enfocarse en la flexibilidad de la empresa y su capacidad de cambiar
Desde la perspectiva empresarial, hay que elegir soluciones que le den flexibilidad y capacidad de cambio a la empresa, y por eso cree que es una tontería quedar amarrado a un SaaS sin ninguna alternativa
En la etapa inicial o cuando aún no hay ingresos, conviene más usar una plataforma que SaaS, y cuando el negocio crece y entra en fase de escalamiento, entonces sí corresponde pensar en cambios tecnológicos de largo plazo
Uso mucho Cloudflare Workers y además escribo mi código para que pueda portarse a cualquier parte
También puede ejecutarse localmente con
wrangler dev, y de hecho puede correr en pure node/bun/deno sin grandes cambiosEl OP (autor de la publicación) no se opone al SaaS en sí (al final recomienda soluciones as a service como Cloudflare o Supabase), sino que el punto central es señalar el costo operativo y la carga de gestionar relaciones que implica contratar y administrar demasiados proveedores
Cuantos menos vendors y menos dependencias haya, más fácil es operar
Implementarlo todo con librerías estándar es una idea demasiado idealista, pero en la práctica es muy difícil
La idea central es proponer que, al comenzar, uses una sola plataforma en vez de mezclar muchos servicios
Prefiero Cloudflare porque estandariza los bindings como
fetch, yfetchse siente en el mundo web como los pipes de UnixEstá la visión de que es irónico intentar evitar el vendor lock-in apostando todo a una sola plataforma y terminando aún más atado a una sola empresa
Porque en SaaS también existe un costo de fragmentación (“impuesto”)
Más bien, esta discusión se parece a una defensa del código abierto
Si fuera código abierto y self-hosted, la mayoría de esos “impuestos” mencionados en el texto (descubrimiento, registro, integración, costos relacionados con desarrollo local) desaparecerían
Cree que el production tax del open source (la carga operativa) puede resolverse con un ecosistema activo, plugins y módulos
Parafraseando la diferencia entre religión y secta: si puedes extraer tus datos en un formato estándar e irte, entonces no es vendor lock-in
También menciona la preocupación de que, cuando el cliente puede obtener sus propios datos, se siente menos agraviado, pero demasiados servicios SaaS hacen imposible eso
Por ahora suelo publicar y distribuir principalmente bajo MIT, y dejar en privado lo importante
La limitación del SaaS es que impide que el cliente disfrute de los beneficios del “costo marginal casi cero” del software
Los operadores SaaS sí reflejan parte de esa ganancia bajando el precio hasta cierto punto, pero cuando hay suficientes usuarios y el precio unitario es alto, al final el usuario de SaaS sale perdiendo
Pero en la etapa inicial de una startup, construirlo uno mismo es una decisión temeraria, y en la fase de “supervivencia” y “minimización de costos iniciales”, SaaS es una estrategia muy sensata
Solo después, cuando el negocio crece y el SaaS se vuelve parte profunda de la operación diaria, aparecen los problemas de lock-in, migración y costo de cambio
Pienso que el problema del SaaS al final también es un efecto secundario del éxito
Por eso existen tantísimos modelos SaaS
Es demasiado atractivo como modelo de negocio: ingresos recurrentes, casi como una pensión, y además poder de fijación de precios