El futuro del SaaS en 2026

Pregunta frecuente:

Estoy trabajando con un sistema que desarrollé quería preguntar como ves este modelo de negocio, hice un sistema POS para restaurant, hace lo típico, un usuario con rol mesero realiza comandas a las mesas que están configuradas y dicha comanda se imprime en la cocina o en la sección de bebidas, una mesa puede tener tantas comandas como sea necesario y caja imprime ticket de pago y cobra, se registra el pago y todo eso. Acordé con los dueños del restaurant que podía vender mi sistema de manera independiente.
Ya lo tengo en otros dos restaurant, aquí va mi pregunta:
He observado que la mayoría de sistemas para este giro son tipo SAAS y se paga una subscripción mensual, yo lo que hago es lo siguiente, mi sistema vive en un docker la BD en una unidad del cliente, y cobro una couta [sic] anual, dejando un mes de prueba, esto trae tantas ventajas como desventajas, del lado del cliente el sistema funciona en su negocio, pero no puede ver reportes y administrar el sistema desde otro lugar, pq vive en local, para mi como producto pues al hacer una nueva actualización debo ir remotamente a cada cliente, pero por otro lado no me preocupo mucho por la seguridad del sistema, pues no es un multitenant.

SaaS en general.

Yo creo que el SasS tendrá una época difícil, por poco tiempo, y después crecerá bastante. La mercadotecnia de IA ofrece que cada restaurant pueda tener su CRM, su POS, su facturación, inventario, contabilidad etc., sin conocimientos de programación. Muchos lo intentarán, y al ver que no es tan fácil como se promete, habrá un rebote y habrá menos resistencia a pagar al Saas. Claro para eso el SaaS necesita haber sobrevivido ese periodo.

Algo que no se está utilizando por los SaaS es la data, esto nadie lo está viendo, pero lo veo en los siguientes dos años, a más tardar. Debido a este periodo oscuro de SaaS, se buscará nuevas formas de monetizar, y una de esas formas es usar la data de los clientes para ofrecer nueva funcionalidad, o sugerir mejores prácticas, o tener comparativas. Por ejemplo

• Tu ticket promedio es de 415.87 pesos, en tu ciudad es de 237.98.
• El número de tickets por mes son 135, en otros restaurantes del mismo giro son 102
• Una buena práctica es separar cada día el IVA cobrado y ponerlo en una cuenta bancaria exclusiva para Impuestos. Así al final del mes tendrás el dinero para entregarlo al SAT.
• etcetera.

Es decir, el SaaS del futuro debe ofrecer conocimiento, además de la funcionalidad. Y la IA puede ayudar al desarrollador profesional a detectar data, mejores prácticas, KPIs, …

Ahora pasando a las situaciones planteadas. Por lo que entiendo de lo expuesto por quien pregunta, el problema principal es el crecimiento lento. Entonces me enfocaré en eso específicamente.

Temas generales como local versus central, nube versus premies, no los trataré más que cuando estén relacionados al problema principal. Todo tiene ventajas y desventajas, no hay una forma única de hacer las cosas, no es que si no lo haces como tu competencia, o como todo el mundo, entonces esté equivocado. Debes analizar qué o cual es el problema y en función de eso, tomar otras decisiones.

Local versus centralizado

En este caso, ventajas si el sistema se tuviera centralizado:

• Sería fácil mostrar el sistema a prospectos. No tendrías que hacer una llamada, mucho menos tener que ir a la localidad del negocio. ¡¡Un formulario de registro, y listo!! puede empezar a utilizarlo. Incluso esto liberaría tiempo que se podría dedicar a desarrollo, o a fortalecer la seguridad del server y del sistema.
• Las actualizaciones las tendrían todos tus clientes, al mismo tiempo. Sin necesidad de tener que visitarlos localmente.
• La atención a fallas y el soporte técnico serían más fáciles de atender.
• Puedes tener acceso a los datos de tus clientes. Tomando las medidas legales y técnicas necesarias, por ejemplo, el consentimiento y la anonimización de los datos (Que los datos los uses de forma estadística, no individual).
• Puedes controlar mejor la licencias / cobros / renovaciones
• Puedes tener mejores planes de servicio. Por ejemplo, pago mensual, semestral, anual. Obviamente el plan mensual es más caro que el semestral y el anual. Y si no se hace el pago, suspendes automáticamente el servicio (en general es más fácil implementar tus políticas de cobros y atrasos, los que decidas)
• Tus clientes pueden ver su información desde cualquier lugar y desde cualquier dispositivo.
• Tienes una versión única en Producción. Esto es más importante de lo que parece. En el modelo local cada cliente tendrá una versión distinta de tu sistema, del sistema operativo, de la BD, de PHP, de Apache. En soporte técnico esto crea muchos problemas para diagnosticar algún problema.

Desventajas / probables desventajas del modelo centralizado

• Onboarding. Quizá cuando vas personalmente al negocio el onboarding es más efectivo. Estableces confianza, y puedes capacitar a quienes utilizarán cada funcionalidad. No sé si actualmente sea así, pero es algo a tomar en cuenta si decides instalando localmente.
• Forzare a implementar la seguridad necesaria en el sistema.
• Forzarte a implementar seguridad en el server (servicios como Cloudflare ayudan).
• Tus clientes necesitan internet para utilizar el sistema
• No te fuerzas a tener muchos clientes de una misma localidad. Estoy convencido que sobre todo al principio en tener muchos clientes en una localidad geográfica, te da ventajas a mediano plazo, tanto a nivel funcionalidad como a nivel posicionamiento y marketing.

Resumen

Si tu sistema ya tiene clientes (es decir un match producto / mercado), mi recomendación para el siguiente paso es centralizarlo. Créeme, es más difícil hacerlo que decirlo. Yo estoy pasando por esto ahora mismo. Pero a largo plazo es lo único que funcionará. Y lo notarás muy pronto, tanto si sigues con el modelo local, o cambias al central. Entonces entra más pronto lo decidas, será mejor.

Define tu Stack.

Yo tomo dos variables para ello. La fortaleza del liderazgo, y lo que ya conozco. En este momento me estoy moviendo de Woo / WP a Laravel. Mi principal razón para el cambio es la parte del liderazgo. En WP ha desaparecido el liderazgo técnico. El ejemplo más reciente es el que por primera vez en WP se regresa una versión de “Release Candidate” a “beta”. La razón: problemas de performance al almacenar información “Real time collaboration”. El problema de performance es al usar la tabla postmeta, que es la forma correcta de usar los estándares y la arquitectura de WP.

1. Nadie ha pedido la funcionalidad RTC (bueno solo una persona).
2. Desde hace más de 10 años se ha pedido muchas veces por muchas personas / grupos el definir una forma standard de agregar tablas, y no que el algún futuro se vayan a tener problemas de performance al usar tablas comunes como posts o postmeta (sí algún vidente / adivino predijo esto hace más de 10 años). Incluso Woo ya implementó esa mejora hace más de tres años: High-Performance Order Storage: Backward Compatibility and Synchronization – The WooCommerce Developer Blog

Es decir, las decisiones técnicas importantes no se toman en cuenta, y otras decisiones para “competir” en marketing, se priorizan. Y entonces se dan cuenta que deberían haber atendido las decisiones técnicas correctas primero.

Te comparto mi proceso de migración.

Laravel ha tenido un crecimiento técnico increíble en los últimos tres años.  Y en el último año, se nota mucho más, y se nota que en los próximos años crecerá más rápido, ya que se ha invertido un buen capital y se han hecho contrataciones muy buenas para mejorar y crecer el framework. Y el contribuidor más importante desde la creación de Laravel es quien está de lleno en el desarrollo técnico. Esto me da confianza para usar el framework en los siguientes 3 – 5 años.

Yo ya conozco PHP por Woo / WP. Entonces el cambio es significativo, pero no muy difícil. La parte más difícil ha sido el saber que ya hay procesos y estándares para cosas tan mundanas como el uso de Log files en PHP. El cambio de includes que se usan en WP versus el concepto de Autoload es otro ejemplo de ello. Hay grandes cambios conceptuales, incluso dentro de PHP.

Independientemente del lenguaje o framework que elijas, ese framework debe tener funcionalidad que hoy considero básica:

• Multitenant / Multi users / Teams / Roles
• Procesos batch
• Queues
• Soportar MariaDB / Postgres
• Buena Documentación
• Tutoriales / Cursos
• Facilidad de trabajar con IA
• Editores y plugins
• Soportar Estándares (como ejemplo PSR-3, PDR-7, etcetera)
• Herramientas para usar paquetes (composer por ejemplo)