Para founders de neobancos, wallets, lending, pagos
De una idea fintech a un producto de verdad, con usuarios reales e ingresos que se pueden medir. Diseñamos y construimos todo: sitio de marketing, app, back-office, integración de pagos e identidad.
La verificación de identidad se cierra, el primer pago sale, y luego la app pasa semanas sin abrirse. Lo que convierte una herramienta en una costumbre todavía no está dentro, y la retención cae antes de que el roadmap se entere.
El cliente cruza a la página de confirmación del banco. Vuelve a la app, la sesión se ha ido, la tarjeta hay que volver a meterla. La mitad de las altas no llega nunca al primer cargo correcto.
Aislamiento de datos, audit log, screening, separación entre clientes. Las respuestas están a trozos en la cabeza de una persona, no escritas dentro del sistema. La negociación se queda ahí, y solo se retoma cuando esas respuestas viven en un sitio que un revisor puede leer.
Un proveedor para identidad, otro para pagos, otro para tarjetas. Una hoja de cálculo sostiene el resto. Cada mes se le roban días al roadmap para cuadrar números que deberían cuadrar solos.
Diseñamos y construimos kiBank: sitio de marketing, app, design system, infraestructura. Cada pantalla existe solo si quita una fricción a quien la usa.
Un producto fintech empieza como una idea y se vuelve real cuando empieza a traer ingresos medibles: una transacción, una suscripción, una venta, un cliente que cambia de estado. Ese momento trae consigo el diseño de la interfaz, la lógica del back-office, la integración con el proveedor de pagos y la verificación de identidad. Trabajamos en todo esto como un solo producto, donde la interfaz y la infraestructura nacen juntas.
Significa que el diseño aprobado sale a producción como se aprobó. La integración de pagos se cose sobre la experiencia en la fase de diseño. Las features que vienen después entran en el mismo producto, sin abrir una obra paralela.
kiBank es la versión en producción de este modo de trabajar. Dibujamos el bloqueo de la tarjeta en el mismo paso en que escribimos las policies sobre la fila de la base de datos. Para quien la usa, kiBank se quedó en un banco que hace su trabajo y se aparta. El resto se quedó dentro del código.
Captura del documento, comprobación de que la persona está delante de la cámara, screening automático contra las listas internacionales de sanciones y de personas políticamente expuestas. Cuando un caso se atasca, el soporte ve dónde se ha cortado, en la misma pantalla que usa compliance.
Partida doble, append-only, event-sourced. El auditor recibe acceso de solo lectura y reconstruye los saldos desde el replay de los eventos, sin una llamada al equipo de finanzas.
La página de confirmación del emisor deja de romper la sesión. El cliente cruza, confirma, vuelve a la app, y aterriza donde estaba, con la tarjeta ya guardada.
Permisos por rol, log firmado de las operaciones del back-office, exportaciones para el reporting regulatorio en los formatos que el regulador pide de verdad, y una dashboard pensada para el equipo de compliance. Lo que se pide en la primera revisión de compras ya está en pie.
Cada capa del stack trabaja para dos momentos. El primero es el día del lanzamiento: la app abre rápido, el pago sale a la primera, el back-office hace lo que necesita el equipo. El segundo es el día en que un cliente regulado empieza a preguntar cómo funciona por dentro.
El sitio de marketing y la parte web de la app viven en el mismo repositorio Next.js. Los datos de los clientes quedan separados directamente en la fila de la base de datos, no en el código de aplicación, y el departamento de compras del cliente enterprise recibe una respuesta que cabe en unas pocas líneas legibles también por quien no escribe código. Los datos de la tarjeta no tocan los servidores: Stripe Elements, o Adyen drop-in, los intercepta desde el navegador y devuelve un token, y la atestación PCI anual se queda en la tarifa más ligera que existe.
El libro mayor es event-sourced, y cada saldo se reconstruye desde el rastro de los eventos sin tocar ninguna stored procedure. Toda la base de código está en TypeScript, desde las consultas a la base de datos hasta las vistas en pantalla. Quien abre el código después del autor original lo lee sin un tour guiado.
Licencia propia no. Para emisión de tarjetas, pagos o captación de depósitos nos apoyamos en un proveedor que sí la tiene, y cableamos nosotros la integración. La contraparte legal sigue siendo la entidad licenciada. Nosotros respondemos del producto y del código de integración.
Sí. Hemos integrado contra Mambu, Thought Machine y un par de sistemas de open banking europeos. Si el core expone una API sensata y un stream de webhooks, nos enchufamos. Si no los expone, le construimos un wrapper alrededor.
Una ruta interna mantiene la sesión mientras el cliente cruza por la página de confirmación de su banco, y para el flujo móvil hay una alternativa dentro de la app. La tarjeta no se vuelve a introducir.
Sí. Partida doble, append-only, event-sourced. El auditor recibe acceso de solo lectura y reconstruye los saldos desde el replay de los eventos. Hemos guiado a auditores por dentro del sistema, y han salido sin preguntas pendientes.
No. Trabajamos junto a los abogados y consultores de compliance que traes tú. Si hace falta, sugerimos partners con los que ya hemos lanzado proyectos, pero los trámites regulatorios no los firmamos nosotros.
Una llamada para enmarcar el trabajo, un número concreto en la primera respuesta, y nada de pitch deck con case studies que parecen todos iguales.
Founders SaaS, de pre-seed a Series A
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