Desarrollo de plataformas SaaS

El problema real de un SaaS no es técnico

Construir la plataforma es la parte que sé hacer y la que se puede estimar. Lo difícil es decidir qué se construye, y ese es el trabajo donde se pierde o se gana el proyecto.

La mayoría de las ideas de SaaS llegan con una lista de veinte funcionalidades porque así se ven los productos maduros de la competencia. Pero esos productos llevan años sumando funciones que sus clientes pidieron después de pagar. Copiar el resultado final salta justamente la parte que los hizo funcionar.

Lo primero que hacemos es al revés: identificar las dos o tres funciones sin las cuales nadie pagaría, y dejar todo lo demás fuera hasta que haya clientes reales pidiéndolo.

Qué hay que resolver antes de escribir código

• Quién paga y por qué. No quién usa: quién firma. A veces no son la misma persona, y el producto se diseña distinto según eso.
• Qué reemplaza. Todo SaaS compite contra algo, aunque sea una hoja de cálculo. Si no queda claro qué deja de hacer el cliente al contratarte, falta definición.
• Cómo se cobra. Por usuario, por uso, por plan, con período de prueba. Esta decisión define cómo se modelan los datos, así que no se puede dejar para después.
• Qué se hace con los datos de cada cliente. El aislamiento entre clientes es una decisión de arquitectura que es cara de cambiar más adelante.

Lo que se construye

Un SaaS tiene partes que no se ven en la demo pero sin las cuales no se puede operar:

• Registro, sesión y recuperación de contraseña, con verificación de correo.
• Organizaciones y permisos. Un cliente no es un usuario: es una empresa con varias personas y distintos niveles de acceso.
• Aislamiento de datos entre clientes, resuelto desde el primer día y no corregido a posteriori.
• Planes y suscripciones. Cobro recurrente, cambios de plan, período de prueba, tarjetas rechazadas y qué pasa cuando alguien deja de pagar.
• Panel de administración propio. Necesitas ver quién se registró, quién está usando el producto y quién está a punto de dejar de usarlo, sin tener que pedirle a nadie que revise la base de datos.
• Métricas de uso. Sin esto no sabes qué funciones justifican seguir invirtiendo.

La arquitectura que evita rehacerlo

Un SaaS que funciona crece, y crecer rompe lo que se construyó sin pensarlo. Las decisiones que tomamos desde el inicio para que eso no pase:

• Base de datos relacional con el modelo multi-cliente resuelto de entrada.
• Infraestructura en la nube que escala por uso, sin servidores que administrar ni capacidad pagada de más mientras tienes pocos clientes.
• Separación entre la aplicación y la lógica de facturación, para poder cambiar de pasarela de pago sin tocar el producto.
• Registro de eventos desde el día uno, porque las preguntas de negocio aparecen después y solo se pueden responder si los datos se guardaron antes.

Nuestra experiencia con esto

Formamos parte del equipo de producto de una plataforma de salud multiidioma con aplicación web y móvil, permisos revocables entre pacientes y profesionales, y análisis de documentos con IA. Está en producción, con aplicaciones publicadas en App Store y Google Play.

También construimos producto propio, donde hicimos todo el recorrido: detección del problema, investigación de mercado, definición, marca, diseño, desarrollo e infraestructura.

Si tu idea todavía está en la etapa de "no sé si esto es viable", eso se resuelve antes y por separado en una consultoría.