Diseñamos y construimos productos fintech
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.
Lo que vemos más a menudo
Las altas llegan, la app se olvida
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 primer pago se rompe en la verificación de dos factores
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.
Una negociación enterprise se queda parada en compras
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.
Finanzas cierra las cuentas a las diez de la noche
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.
kiBank, un neobanco que diseñamos y construimos por completo
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.
Cómo afrontamos el fintech
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.
Qué ponemos en producción en este sector
Verificación de identidad que el equipo de soporte cierra sin abrir un ticket al proveedor
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.
Un libro mayor que el auditor abre por su cuenta
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.
Un primer pago que aguanta la verificación de dos factores
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.
Las pruebas de compliance que pide el primer cliente enterprise
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.
El stack que elegimos para fintech
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.
Preguntas que hacen los founders
¿Tenéis una licencia propia o os apoyáis en un partner?
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.
¿Os podéis conectar a nuestro core banking?
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.
¿Cómo gestionáis el primer pago de un cliente nuevo?
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.
¿El libro mayor aguanta una auditoría financiera?
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.
¿Os ocupáis también de los trámites regulatorios?
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.
Cuéntanos el producto
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.