Para founders SaaS, de pre-seed a Serie A
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Founders fintech que desarrollan neobancos, wallets, lending, pagos
Fabricantes mid-market que desarrollan cockpits operativos
Founders que desarrollan productos cloud para consumer y utility apps
Equipos del sector público que entregan servicios a los ciudadanos