Diseño e ingeniería para founders SaaS
Construimos el producto de suscripción entero. La página de marketing es la parte fácil. Lo difícil es el sistema de pagos que tiene que funcionar al primer cobro, el acceso que tiene que pasar la primera auditoría de seguridad, y el producto que tiene que enseñar su valor antes de que el cliente piense en darse de baja.
Lo que vemos más a menudo
La facturación son cinco herramientas distintas que ni siquiera se hablan
El founder acaba pasando las tardes manteniendo en pie el sistema de cobros, la gestión de suscripciones, los emails automáticos al cliente y el documento compartido para alargar trials caducados. A final de mes nadie sabe de verdad cuántas semanas de runway se han quemado.
Un MVP no-code que ha puesto techos donde no debía
El founder llegó con un prototipo que le consiguió los primeros tres clientes, y al cuarto el techo del no-code se nota. Las vistas internas son falsas, no hay registro de operaciones, y el primer prospecto que pregunta cómo se mantienen separados los datos de cada cliente bloquea la negociación.
Una página de precios escrita para ingenieros, no para quien compra
Los planes están copiados de un competidor. La tabla comparativa es demasiado larga y nadie la lee entera. Lo que el cliente consume por encima del plan no llega nunca a la factura.
Moko, el espacio de trabajo para el soporte al cliente
Diseñamos y desarrollamos Moko desde cero, desde la bandeja de mensajes hasta el portal donde el cliente busca por su cuenta. Cada pantalla que el equipo usa cada día se construyó con el mismo cuidado, dentro de un único design system.
Cómo construimos Moko
Moko sustituye todo el espacio de trabajo de un equipo de soporte al cliente, desde la bandeja de mensajes hasta el portal donde el cliente busca por su cuenta. El brief era claro: cada pantalla terminada al mismo nivel de cuidado, sin página principal pulida seguida de vistas a medio hacer. Es la forma de trabajo que rompe casi todas las herramientas de soporte después del primer lanzamiento. La bandeja se lleva toda la atención, los informes siguen en bruto durante meses, y el portal del cliente lo añade alguien la noche antes de salir a producción.
El design system era el proyecto
Que todas las pantallas tengan el mismo acabado significa que el design system lleva el proyecto, no al revés. Empezamos por las partes que cada vista iba a compartir, desde los botones hasta las tablas y los gráficos, y sobre esa base construimos las áreas del producto. Ninguna pantalla recibió un trato especial, ninguna área pidió una variante solo para ella.
La bandeja de mensajes es la página más importante
La bandeja es el sitio donde el agente de soporte vive durante la jornada. La ventana de respuesta cambia de color cuando se pasa de la respuesta pública para el cliente a la nota interna del equipo, así el modo queda claro antes de pulsar enviar. Los cambios de estado son inmediatos y se pueden deshacer, y la interfaz nunca se queda esperando a la red. Las etiquetas y la prioridad se modifican directamente desde la fila del mensaje, sin abrir una ventana aparte. Encima de las conversaciones largas aparece un resumen automático que cuenta cómo se siente el cliente, en qué plan está, y qué podría servirle como próximo paso.
Toda la página se puede usar solo con el teclado. Los atajos cubren los pasos que un agente repite cien veces al día. Quien los aprende ya no vuelve al ratón.
Un perfil de cliente que no se inventa nada
Cada cliente trae consigo su propia historia. El perfil resume en una franja las estadísticas principales, muestra todos los tickets abiertos y cerrados del cliente, y permite añadir campos personalizados directamente desde la fila, sin abrir una ventana aparte. La misma ficha aparece también dentro de la bandeja. Quien abre una conversación ve directamente en qué plan está el cliente, desde dónde escribe, y cuáles han sido los últimos tickets. Todo se queda en la misma pantalla.
Una base de conocimiento para el equipo y para el cliente
La base de conocimiento la escribe el equipo de soporte, y la leen los clientes. Por dentro es una herramienta editorial, con las categorías, los borradores, los artículos publicados. Por fuera, en la dirección /help, es una página de consulta de verdad, con la búsqueda en primer plano, las categorías agrupadas, y un índice dentro de cada artículo. Las dos caras leen de los mismos datos. El agente que actualiza un artículo para cerrar un ticket sabe que el mismo artículo es el que el cliente encontrará buscando por su cuenta.
Los dos temas pensados juntos desde el principio
El tema claro y el oscuro no se añadieron uno después del otro. Se pensaron juntos desde el principio del proyecto, y trabajamos con ambos activos durante el desarrollo. El producto saca los colores y los tamaños de fuente del design system, y ningún valor está escrito a mano dentro de una pantalla concreta. Cuando se cambia de tema, los gráficos y las etiquetas de estado cambian junto con los botones, y ninguna parte se queda atrás. Cambiar el color de una categoría de gráficos en todo el producto es una modificación en un único sitio.
Por qué importa para quien lanza un producto de suscripción
Un producto SaaS completo es un sistema en el que el equipo de soporte, la administración, la dirección y el cliente encuentran cada uno su propio sitio para trabajar. Moko reúne todo eso dentro de un único design system, y el producto sigue pareciendo el mismo producto cuando el equipo se duplica o la marca cambia de dirección.
Qué ponemos en producción en este sector
Acceso con datos separados por cliente
Cada cliente ve solo sus propios datos, y el control se hace dentro de la base de datos. Es la garantía por escrito que el equipo de seguridad del primer cliente enterprise querrá ver antes de firmar.
Facturación recurrente que aguanta en los bordes
Subidas de plan a mitad de mes, bajadas, renovaciones y reintentos tras un cobro fallido se calculan al céntimo. Las notificaciones que llegan de Stripe se procesan una sola vez, aunque lleguen dos, y el registro contable interno se queda alineado.
Medición de quién está entendiendo el producto de verdad
Trazamos las acciones que predicen la renovación, no los clics genéricos. Se sabe pronto quién se va a quedar y quién está a punto de marcharse, antes de que llegue el email de baja.
Cabina interna para tu equipo
Reembolsos, cambios de plan, acceso a los datos de un cliente cuando hay un problema, todo desde una interfaz. Tu equipo deja de entrar en la base de datos a mano.
Compliance lista para la primera auditoría
Permisos distintos para cada rol del equipo, registro de las operaciones que cuentan, exportación y borrado de datos conforme al RGPD. Lo que el primer cliente enterprise pide ver ya está ahí, listo.
Defensa frente al abuso de los trials
Comprobamos el dominio del email, reconocemos el dispositivo que se registra, y ponemos un tope al número de intentos desde la misma red. Abrir una ventana de incógnito ya no basta.
Un stack que se amortiza dos veces
Cada capa de este stack se amortiza dos veces. La primera cuando pones en producción la primera versión del producto. La segunda cuando empiezas a crecer, a contratar, o a contestar las preguntas duras del departamento de compras del primer cliente enterprise. Elegimos el stack que aguanta en ese segundo momento, no el que solo funciona hoy.
La parte pública del sitio, el producto dentro de la app y el panel del administrador viven en un único repositorio sobre Next.js. La página de precios es estática y se posiciona bien en los buscadores. El producto, una vez dentro, va rápido desde el primer clic. El equipo de marketing y el de producto trabajan sobre el mismo código, sin discusiones sobre dónde meter un flujo nuevo.
Los datos de los clientes quedan aislados directamente en la base de datos, no por culpa del código de aplicación. La razón es una sola. La primera negociación seria con un cliente grande pasa por una auditoría de seguridad, y esa auditoría hace siempre la misma pregunta, cómo garantizas que el cliente A no pueda ver los datos del cliente B. Con un Postgres gestionado la respuesta cabe en unas pocas líneas de código, y se puede poner por escrito en el contrato. En la misma base de datos viven también las cuentas de los clientes, los archivos subidos, las actualizaciones en tiempo real, y tu equipo deja de pegar tres servicios que ni se ponen de acuerdo sobre quién es el usuario.
La facturación corre sobre Stripe. Las suscripciones, los cambios de plan y los reintentos tras un cobro fallido los gestiona Stripe por nosotros, y la capa de facturación crece con el producto sin pedir una reescritura cuando llegan los primeros clientes de verdad. Si Stripe tiene un problema puntual, el registro contable interno se queda alineado y ningún cliente se cobra dos veces. El cliente gestiona su propio plan desde el portal de Stripe, y tu soporte deja de hacer también de departamento de facturación.
La protección frente al abuso de uso pasa por un servicio Redis gestionado, sin un servidor que mantener. Los archivos de los clientes viven dentro de un object storage que no cobra cada descarga, y un usuario que baja mil veces el mismo archivo no se convierte en una sorpresa de cuatro cifras en la factura del mes siguiente.
Todo el código está escrito en TypeScript, desde las consultas a la base de datos hasta las vistas en pantalla. Es la ventaja menos vistosa y la más importante. Cuando un ingeniero deja el equipo, cuando una función cambia de nombre, los errores aparecen al momento en lugar de salir seis meses después en producción. Quien abre el código al día siguiente se mueve sin una visita guiada.
Preguntas que hacen los founders
Ya tengo un MVP en Bubble, ¿se puede partir de ahí?
Sí, lo migramos. La lógica construida dentro de Bubble se reescribe en código real, los datos pasan a Postgres, y el producto nuevo se publica como aplicación de verdad, no como prototipo no-code con el techo bajo.
¿Solo necesito la parte de facturación, la hacéis?
Sí, con un perímetro claro. Construimos el módulo de facturación sobre Stripe como pieza aislada, con las integraciones conectadas y una vista interna para tu equipo. El alcance y el precio dependen de lo complejo que sea el modelo de precios.
¿Cómo gestionáis el abuso de los trials gratuitos?
Lo tratamos como una capa de seguridad, no como un truco de marketing. Comprobamos el dominio del email, reconocemos el dispositivo que se registra, y ponemos un tope al número de intentos desde la misma red. Abrir una ventana de incógnito ya no basta.
¿Cuál es el alcance mínimo para llegar a los primeros clientes que pagan?
Tres cosas al principio. El acceso de los clientes, un sistema de facturación que funciona, y el flujo central del producto bien hecho. Las vistas internas y las integraciones llegan después, cuando los primeros clientes que pagan te dicen cuál hace falta primero. Lo que sobra se recorta antes de construirlo, no después.
¿Os quedáis después del lanzamiento?
Dos opciones. La primera es una entrega limpia a tu equipo, con toda la documentación y el design system en sus manos. La segunda es quedarnos como partner continuo del producto. No desaparecemos después del lanzamiento.
Cuéntanos tu SaaS
Una llamada para enmarcar el proyecto, un número concreto en la primera respuesta, y nada de pitch deck con case studies que parecen todos iguales.