Qué lo hace SaaS y no una herramienta interna
Una aplicación interna tiene un solo cliente, y ese eres tú. Puedes definir el proceso, capacitar a los usuarios y corregir una mala suposición diciéndole a todos que el lunes se hace distinto.
Un producto SaaS tiene muchos clientes que no comparten tus suposiciones. Cada uno necesita sus datos separados de los de los demás, tiene que poder registrarse y empezar a trabajar sin una llamada contigo, y se va a ir si el cargo mensual deja de valer la pena. Esos tres hechos moldean casi todas las decisiones técnicas que siguen.
Si no tienes claro cuál de las dos estás construyendo, la guía de sitio web o aplicación web cubre el paso anterior a este. Muchos buenos negocios necesitan una herramienta interna y nunca necesitan un producto.
Valídalo antes de construirlo
Los productos SaaS más caros son los que se construyeron completos antes de pedirle a nadie que pagara. El fracaso rara vez es técnico: el software funciona y nadie lo quiere a ese precio.
Maneras económicas de averiguarlo antes:
- Habla con diez personas que tengan el problema y pregunta qué hacen hoy al respecto, no si usarían tu idea. Todo el mundo dice que sí a una hipótesis.
- Averigua cuánto pagan hoy, en dinero o en horas. Un problema en el que nadie está gastando ya es una primera venta difícil.
- Ejecuta el proceso a mano para un cliente. Si puedes entregar el resultado con una hoja de cálculo y una tarde, ya tienes un primer cliente y una especificación.
- Cobra antes de que el producto exista, aunque sea un anticipo. Es la única pregunta cuya respuesta significa algo.
Con lo que hay que tener más cuidado es con construir para ti mismo. Un software que resuelve tu propio problema a la perfección es una buena herramienta interna y muchas veces un producto con exactamente un cliente contento.
Qué entra en la primera versión
Una primera versión debería permitirle a un tipo de cliente hacer una cosa valiosa, pagar por ella y volver la semana siguiente. Todo lo demás es una decisión posterior, y casi todo se decidirá distinto cuando haya gente real usándolo.
Lo que normalmente tiene que estar en la versión uno:
- Registro, inicio de sesión y recuperación de contraseña.
- El único proceso para el que de verdad existe el producto.
- Una forma de cobrar, aunque al principio sea una factura manual.
- Suficiente registro de actividad para responderle a un cliente que pregunta qué pasó con sus datos.
Lo que casi siempre puede esperar: invitaciones de equipo, permisos detallados, inicio de sesión único, un panel de administración con gráficas, una API pública, aplicaciones móviles nativas, recorridos guiados dentro del producto y una página de preferencias que nadie ha pedido todavía.
La excepción es la sección siguiente, que es la única decisión de arquitectura que no puedes dejar para después.
Multiempresa: la decisión que no puedes aplazar
Cada registro de un producto SaaS pertenece a un cliente, y el sistema tiene que imponer esa frontera en lugar de confiar en que la interfaz no muestre el botón equivocado. Meter eso después en una aplicación escrita para un solo cliente es casi reescribirla, y por eso pertenece a la primera semana.
Dos preguntas definen su forma.
¿Un cliente es una persona o una organización? Si varias personas de la misma empresa van a compartir datos, la cuenta es de la organización y las personas pertenecen a la cuenta. Empezar con una cuenta por persona y descubrir después que los clientes quieren equipos es una de las correcciones más caras de esta lista.
¿Los datos de un cliente tienen que estar físicamente separados? Para casi todos los productos, una sola base de datos con un identificador de cliente en cada registro es lo correcto, y la frontera se impone en la capa de datos para que ninguna consulta pueda cruzarla por accidente. Una base de datos por cliente a veces la exige un contrato o un regulador, y vuelve más difícil cada cambio futuro, así que hazlo solo cuando alguien lo esté exigiendo de verdad.
Cuentas, roles e invitaciones
No construyas la autenticación. El guardado de contraseñas, los flujos de recuperación, el manejo de sesiones, el segundo factor y la eventual exigencia de inicio de sesión único están resueltos por servicios que cuestan menos que el tiempo de hacerlo mal, y hacerlo mal es una brecha y no un error.
Lo que sí merece tu propio pensamiento es la capa de arriba. Los roles deberían ser reglas sobre registros y no una lista de pantallas: un dueño ve todo lo de su organización, un gerente ve su sucursal, un cliente ve solo lo que le pertenece. Escritos así siguen siendo correctos cuando agregas funciones; escritos como una lista de botones ocultos, no.
Después, las partes que se olvidan: invitar a un colega que todavía no tiene cuenta, transferir la propiedad cuando la persona que se registró deja la empresa, y quitar accesos de modo que de verdad desaparezcan y no solo se escondan.
El precio moldea el software
Decide cómo vas a cobrar antes del desarrollo, porque el modelo de precios es un modelo de datos. Por usuario significa contar e imponer usuarios. Por consumo significa medir algo con la precisión suficiente para ponerlo en una factura y defenderlo. Una cuota fija al mes es lo más simple que puede funcionar y está subestimada para una primera versión.
Usa un proveedor de pagos para todo esto y resiste la tentación de construir un sistema de facturación. Lo que estás comprando no es el formulario de la tarjeta, es todo lo que lo rodea:
- Pruebas gratuitas, mejoras y bajas de plan, y la aritmética de prorrateo que nadie disfruta escribir dos veces.
- Pagos fallidos y reintentos, que son una parte sorprendente de los ingresos perdidos si nada se encarga de ellos.
- Facturas y recibos que el contador de tu cliente acepte.
- Impuestos sobre ventas e IVA, que dependen de dónde está tu cliente y no de dónde estás tú.
- Un registro de quién tiene derecho a qué en este momento, que tu aplicación lee en lugar de guardar su propia copia.
Lo único que conviene que sea tuyo es la correspondencia entre una suscripción y lo que desbloquea el producto. Mantenla en un solo lugar. La lógica de permisos de pago repartida por el código es como los clientes terminan con accesos que no están pagando, o bloqueados de algo que sí.
Cuando el dinero va hacia otras personas
Cobrarle a tus propios clientes es rutinario. Pagarle a otras personas a través de tu plataforma es otro producto, y hay que nombrarlo el primer día en lugar de tratarlo como una función para después. Un marketplace, una plataforma de reservas que le paga a los proveedores, o cualquier cosa donde te sitúas entre dos partes entra aquí.
Lo que viene con eso: verificar la identidad de quienes reciben los pagos, retener fondos y programar los envíos, manejar reembolsos y contracargos después de que el dinero ya se movió, y decidir quién es legalmente el comerciante registrado. Las plataformas de pago tienen productos exactamente para esto, y usar uno casi siempre es lo correcto.
Paganki es un ejemplo construido: una plataforma multiempresa con pagos por Stripe Connect, funcionando en cinco idiomas.
El trabajo que empieza el día del lanzamiento
Un producto SaaS es un servicio, y el desarrollo muchas veces es la mitad más pequeña de lo que cuesta a cinco años. Las partes que es fácil dejar fuera del presupuesto:
- Hosting, base de datos y respaldos que escalan con la cantidad de clientes.
- Los servicios medidos de abajo: entrega de correo, almacenamiento de archivos, autenticación, pagos.
- Actualizaciones de seguridad de todo aquello sobre lo que está construido el producto, que dejan de ser opcionales en cuanto guardas datos de otras personas.
- Soporte, incluida la pregunta que llega a las siete de la tarde porque alguien no puede terminar su trabajo.
- Restaurar los datos de un cliente sin tocar los de nadie más, algo que conviene haber probado antes del día en que haga falta.
- Cambios, porque un producto que se usa genera peticiones.
Si el plan no tiene presupuesto para el segundo año, construye algo más pequeño. Un producto abandonado con clientes pagando encima es peor que no haber lanzado nunca.
Qué se rompe con cien clientes, y con mil
Los problemas tempranos suelen ser de correctitud, y los posteriores son de un cliente afectando a otro. Vale la pena diseñar contra el segundo tipo desde temprano, porque es barato prevenirlo y disruptivo corregirlo.
El orden habitual en que se rompen las cosas: los informes que eran rápidos sobre los datos de un cliente se vuelven lentos sobre los del cliente más grande; una tarea larga iniciada por un cliente retrasa la de todos los demás, así que el trabajo se mueve a una cola; el correo empieza a caer en spam cuando sube el volumen, así que el envío necesita su propio dominio y reputación; y el soporte se vuelve imposible sin una manera de ver lo que un cliente concreto vio de verdad.
Ninguna de estas hay que resolverla en la versión uno. Hay que dejarlas posibles sin reescribir lo construido, lo que sobre todo significa mantener honestas las fronteras entre clientes y no poner trabajo lento dentro de la petición que una persona está esperando.
Vender más allá de un mercado
Si en el plan hay clientes fuera de tu primer mercado, el momento barato para preverlo es el principio. Meter un segundo idioma en un producto que ya está corriendo significa tocar cada pantalla, cada correo y cada mensaje de error, y por eso tantas veces no ocurre.
Tres cosas que conviene decidir en lugar de descubrir: si la interfaz necesita más de un idioma, si vas a cobrar en más de una moneda, y si los impuestos los maneja tu proveedor de pagos o tú.
En el sur de Florida el caso bilingüe es normal y no exótico. Un producto que se vende en inglés y en español necesita los dos en toda la experiencia, incluidos los correos de pedido y de aviso, que es la parte que suele quedarse en inglés.
Que alguien lo construya
Si ya validaste la idea y quieres la primera versión bien hecha, con la separación entre clientes, las cuentas y los cobros decididos a propósito en lugar de descubiertos, eso es lo que hace mi servicio de aplicaciones web. La primera conversación es sobre el proceso y los clientes, no sobre la tecnología.
Ejemplos construidos: Paganki es una plataforma SaaS multiempresa con pagos por Stripe Connect en cinco idiomas, el Athlean-X Portal entrega los productos comprados a miles de usuarios con sesión como una aplicación web progresiva que funciona sin conexión, y Parking Operations Analytics convierte datos de transacciones en vivo en informes de ingresos por turno en varios estacionamientos.