Diseño e ingeniería para founders SaaS
Checkout integrado con Stripe, auth multi-tenant, dashboards que muestran el valor antes de que el cliente se vaya. El producto subscription completo, no solo una landing.
Los problemas que más escuchamos
Stripe, Customer.io, Intercom y un Google Sheet para extender trials
Cinco herramientas que no se hablan, nadie sabe cuántas semanas de runway se queman al mes.
Un founder corrigiendo eventos de onboarding a las 11 de la noche
Sin tracking de activación, sin funnel, sin forma de saber qué paso mata la conversión.
Dashboards que dicen qué pero nunca por qué
Tus clientes se van y el equipo se entera por el email de cancelación. El valor nunca aparece donde importa.
Una página de precios que habla a ingenieros, no a compradores
Planes copiados de un competidor, tabla comparativa que nadie lee, sin metering ligado al billing.
Moko · ocho áreas, un design system
Un espacio de trabajo para soporte al cliente, diseñado y construido desde cero. Inbox, detalle de ticket, clientes, knowledge base, informes, macros, ajustes, portal del cliente. Ocho áreas de producción, un design system, un solo equipo.
Dentro de la build de Moko
Moko sustituye las áreas cotidianas donde vive un equipo de soporte al cliente: inbox, detalle de ticket, clientes, knowledge base, informes, macros, ajustes y portal del cliente. El brief era entregar cada área con el mismo nivel de acabado, no una página principal pulida seguida de siete áreas dejadas a medias. Esa es la forma de trabajo que rompe la mayoría de las herramientas de soporte después del lanzamiento: el inbox se lleva toda la atención, los informes nunca reciben el mismo cuidado, el portal del cliente es un añadido de última hora. Tratamos las ocho áreas como iguales, y el design system absorbió el coste de hacerlo.
El design system era el proyecto
Ocho áreas que comparten el mismo acabado significa que es el design system el que lleva el proyecto, no al revés. Empezamos construyendo los componentes que inbox, perfil de cliente e informes iban a compartir, es decir botones, badges, status pills, modales, dropdowns, filas de tabla y gráficos, y luego ensamblamos las superficies sobre esa base. Ninguna pantalla recibió un trato especial, ninguna superficie negoció una variante one-off, y el equipo que terminó usando el sistema a escala era lo bastante pequeño como para que la consistencia fuera una feature, no una carga de proceso.
El inbox keyboard-first
El inbox es la página más importante. Un agente se mueve dentro continuamente. El composer alterna entre respuesta pública y nota interna con un cambio de color que hace inequívoco el modo antes de enviar. Los cambios de estado son optimistas con rollback, así que la interfaz no se queda esperando al servidor. Las etiquetas y la prioridad se editan inline, nunca en un diálogo. Una tarjeta de AI summary aparece sobre los hilos con tres o más mensajes y muestra sentimiento, contexto del plan y un siguiente paso sugerido. Un refresh con un clic regenera la sugerencia cuando el agente quiere otro ángulo.
El inbox tiene cinco atajos de teclado: navegar la lista de conversaciones, moverse entre estados, abrir el AI summary, insertar una macro, enviar la respuesta. El overlay de ayuda los enseña en el mismo sitio donde se usan. Quien los aprende ya no vuelve al ratón.
Un perfil de cliente que no miente
Cada cliente llega con su historia. El perfil 360 combina una franja de estadísticas con la lista completa de tickets y un editor de custom fields que añade, edita y elimina inline con feedback inmediato. El mismo esquema alimenta el drawer del inbox, así un agente que abre una conversación ya ve plan, ubicación, CSAT histórico y los últimos tickets del cliente sin salir del hilo. Sin pestañas que cambiar, sin sidebar que esperar. Una sola forma de dato, usada en dos sitios.
Una knowledge base que son dos productos en uno
El lado admin es un CMS para contenido de soporte con categorías, borradores y estados publicados. El lado público, servido en /help, es un layout estilo marketing con hero search, cards de categoría e índice por artículo. Los dos leen de los mismos datos, así un agente que actualiza un artículo no tiene que pensar en qué superficie lo verá el lector. El mismo artículo que ancla una respuesta de soporte es el artículo que el cliente encuentra en self-service vía búsqueda.
Las macros como sistema de templating
Las macros no son un menú de respuestas rápidas, son un sistema de templating ligero. Las variables se resuelven desde el ticket y el cliente en vivo en el momento en que el agente inserta la macro, así la misma plantilla parece escrita para la persona del otro lado. La combinación de macros, tarjeta de AI summary y ediciones inline es lo que convierte el inbox de una lista en un espacio de trabajo.
Light y dark desde el primer commit
Cada pantalla nace en light y en dark desde el primer commit. Todo el producto es token-driven: nada de colores hardcoded, nada de pesos de fuente hardcoded, nada de inline style en ninguna parte del código. El design system lleva la paleta, la escala tipográfica, los radius y los niveles de elevation en los dos temas. Gráficos y badges leen de los mismos tokens que los botones, así un cambio de tema nunca miente sobre qué es interactivo. En la superficie de informes viven cuatro tipos de gráfico, y cada uno está atado a los tokens del design system, así un cambio de color en el sistema se propaga por el producto en un solo commit.
Por qué esta forma importa para un founder SaaS
Un SaaS completo no es la página de marketing más un MVP. Es el inbox en el que trabaja el equipo de soporte, el registro contable que lee el equipo de finanzas, los informes que el founder revisa antes de un board meeting, y el portal donde el cliente entra para gestionar su plan. Moko es la forma de trabajo que cierra todo ese circuito con un solo design system, no ocho equipos pegando ocho superficies inconsistentes. El resultado es un producto que no pide ser reescrito cuando el equipo crece o la marca evoluciona.
Lo que el trabajo entregó
Ocho áreas bajo un solo design system. Cinco atajos de teclado en el inbox. Cuatro tipos de gráfico atados a tokens del design. Cero valores hardcoded en el código.
Qué entregamos en este vertical
Auth multi-tenant con Supabase RLS
Row-level security que aguanta una auditoría, aislamiento entre tenants garantizado a nivel de fila.
Billing Stripe con prorrateo
Checkout, Subscriptions, Customer Portal, router de eventos webhook.
Onboarding con tracking de activación
Eventos de funnel ligados a las acciones que predicen retención.
Dashboard admin
Cockpit interno para soporte, reembolsos, migraciones de plan.
Router de eventos webhook
Handlers idempotentes, cola de reintentos, logging dead-letter.
Permisos por rol
Owner, admin, member, billing. Validados en servidor, no solo en UI.
Metering de uso
Vincula consumo a límites de plan y facturación posterior.
Prevención de abuso de trial
Heuristic sobre email y fingerprint, sin reset-en-incógnito.
API surface
Versionada, documentada, rate-limited. Los clientes dejan de pedir exports CSV por email.
Feature flags
Envía en branch, rollout por tenant, kill switch en oncall.
Audit log
Cada acción privilegiada atribuible, exportable, consultable.
Export y borrado GDPR
Self-service, un botón, cero tickets a ingeniería.
Un stack pensado para el ciclo del SaaS
Cada capa de esto existe para amortizarse dos veces: la primera cuando estás poniendo en línea la primera versión del producto, la segunda cuando empiezas a crecer, a contratar o a enfrentarte a las preguntas duras del departamento de compras de un cliente importante. Elegimos el stack que aguanta justo en ese segundo momento.
El sitio de marketing, la dashboard dentro de la aplicación y el panel de administración están todos dentro del mismo código, construido sobre Next.js App Router, así que la página de precios se posiciona en Google como si fuera una página estática, la dashboard se carga rápido al primer clic del usuario, y tus desarrolladores no pierden media jornada discutiendo qué framework tiene que ocuparse del flujo de registro. Un solo repositorio, un solo despliegue, y el equipo de marketing y el equipo de producto trabajan en el mismo sitio.
Los datos de los clientes están aislados a nivel de base de datos, no en el código de la aplicación, y este es el punto clave: el primer contrato importante que vayas a cerrar pasará por una revisión de seguridad, y esa revisión siempre hará la misma pregunta, es decir cómo garantizas que el cliente A no pueda ver los datos del cliente B. Con Supabase Postgres y la seguridad a nivel de fila la respuesta es demostrable en una sola pantalla de código, y la puedes poner por escrito. La misma base de datos se ocupa además de las cuentas de usuario, de las subidas de archivos y de las actualizaciones en tiempo real, así no terminas pegando tres servicios distintos que ni siquiera se ponen de acuerdo sobre quién es el usuario.
Suscripciones, cambios de plan hacia arriba y hacia abajo, reintentos de cobro, facturas, reembolsos, todo construido sobre Stripe Subscriptions y Customer Portal, de modo que la capa de facturación crezca con el producto en lugar de pedir una reescritura cuando empieces a escalar. Conectamos las piezas para que una caída de Stripe no deje tu registro contable fuera de sincronía. Los clientes gestionan su propio plan, lo cancelan, lo reactivan, descargan los recibos, y el soporte deja de hacer también de departamento de facturación.
Una infraestructura que no se dispara en costes mientras el producto crece: Upstash Redis cerca del usuario se encarga de limitar las llamadas y de proteger contra abusos sin que tengas que mantener un servidor, mientras Cloudflare R2 guarda los archivos de los clientes, así un usuario que descarga el mismo archivo a repetición no se convierte en una sorpresa de cuatro cifras en la factura. Costes predecibles, sin sorpresas.
Cada llamada a la API, cada consulta a la base de datos y cada elemento de interfaz está tipado con TypeScript: es un beneficio poco vistoso pero crítico, porque cuando alguien deja el equipo, cuando sustituyes a un desarrollador, cuando renombras una funcionalidad, el producto no se rompe en silencio. La persona que abre el código justo después puede moverse dentro de él sin necesidad de 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 la reescribimos en código real, los datos pasan a Postgres, y el producto nuevo va en línea como una aplicación de verdad, no como un prototipo no-code con un techo encima.
¿Y si solo necesito la parte de facturación?
Sí, y con un perímetro claro: Stripe Checkout, Stripe Subscriptions y Customer Portal como módulo aparte, con los webhooks conectados y una vista de administración para tu equipo. El alcance y el precio dependen de lo articulado que sea el modelo de pricing.
¿Cómo evitan el abuso de los trials gratuitos?
Con tres controles superpuestos: heurística sobre el dominio del email, huella del navegador en el momento del registro, y un tope por dirección IP y por dispositivo sobre los intentos consecutivos. Lo tratamos como una capa de seguridad, no como un truco de marketing.
¿El seguimiento de la activación lo configuran ustedes o lo traigo yo?
Las dos opciones. Tenemos un default del que nos fiamos (PostHog más un pequeño wrapper en el lado servidor), y si tienes ya una herramienta que pagas nos conectamos a esa.
¿Cuál es el alcance mínimo que entregan para llegar a los primeros clientes que pagan?
Autenticación, facturación y un único flujo central bien hecho. Los dashboards, las vistas de administración y las integraciones llegan después, cuando los clientes que pagan te dicen cuál necesitan primero. Recortamos lo superfluo antes de construir, no después.
¿Se quedan también después del lanzamiento?
Dos caminos posibles: entrega limpia con toda la documentación y el design system en manos de tu equipo, o nos quedamos como partner continuo. No desaparecemos después del lanzamiento.
¿Y si quiero mantener la agencia que me lleva el marketing?
Sin problema. Nosotros nos ocupamos de la parte de producto, ellos siguen con el sitio de marca, y nos coordinamos sobre el CMS compartido y la analítica de manera que ninguno de los dos trabaje a ciegas.
¿Cuánto cuesta un proyecto completo?
Las franjas de precio están en el formulario de contacto. Tras una llamada para enmarcar el proyecto respondemos con un número concreto, no con un folleto.
Cuéntanos tu SaaS
Una llamada para enmarcar el proyecto, un número concreto en la primera respuesta, cero teatro de agencia.