Kinbara: del plan a producción en una mañana

Un plan guardado a las 10:49. La web, la API y el correo, en producción a las 12:30. Es el mismo día, el 23 de agosto de 2026, y las dos horas salen del historial del repositorio, no de la memoria. Esta es la historia de Kinbara, un producto nuestro. La contamos porque es el único caso que podemos enseñar entero: el código, las fechas y cómo se opera.

Este caso es para quien quiere una plataforma propia funcionando pronto y bien hecha. Si lo que buscas es quién te la construya y la mantenga, la página es desarrollo de software a medida. Y si quieres que lo miremos contigo, cuéntanos el caso.

Qué es Kinbara

Kinbara es un marco de 116 principios para vivir con más conciencia. Tiene un libro, una web pública que propone cada día un principio con una acción concreta, un correo para quien quiere recibirlo y grupos de práctica con inscripción de pago. Es de Arteco Consulting. Lo diseñamos, lo construimos y lo operamos nosotros.

Para nosotros es también un banco de pruebas. Lo que funciona aquí lo llevamos a los proyectos de clientes, y al revés.

El punto de partida

El contenido llevaba meses escrito. La plataforma era una lista de requisitos:

• Una web rápida, que se pueda instalar en el móvil y que guarde el diario personal solo en el dispositivo de quien lo escribe.
• Altas con doble confirmación y un correo diario que salga solo, a su hora, todos los días.
• Cobro de inscripciones y suscripciones, con su portal para que cada cliente gestione la suya.
• Copias de seguridad que se puedan restaurar de verdad.
• Y una regla editorial que se cumple sola: el texto del libro se queda en el libro.

Cómo fue el día

Todo lo que sigue tiene su commit con fecha y hora.

Hora	Qué quedó hecho
10:49	Plan de construcción guardado en el repositorio
11:07	Web con las 116 páginas de principio, el índice y el buscador
11:18	Altas con doble confirmación y la primera prueba de extremo a extremo
11:51	Imagen de la web y manifiestos de Kubernetes
12:09	API en Spring Boot con base de datos, migraciones y pruebas
12:30	Primer despliegue completo en producción: kinbara.com, la API y el servidor de correo
12:39	Comprobación automática contra producción
15:59	Copias de seguridad diarias en la nube, con la restauración probada
17:50	Cobro con Stripe en marcha, con confirmación firmada y correo al cliente

Al día siguiente llegaron la suscripción mensual, el portal del cliente y una conciliación que cada madrugada cruza lo que dice Stripe con lo que dice la lista de correo. Si alguien deja de pagar, sale de la lista sin que nadie tenga que acordarse.

Cómo está hecho

La arquitectura es deliberadamente conocida. Cada pieza tiene años de uso detrás y gente que sabe mantenerla:

• Web: Astro 5 con islas de Preact. Se instala como aplicación y funciona sin conexión. El buscador va incluido en la propia web.
• API: Java con Spring Boot 4, PostgreSQL y Flyway para las migraciones. Las pruebas levantan una base de datos real en un contenedor.
• Correo: Listmonk con plantillas propias y dominio autenticado. Los correos salen sin píxeles de seguimiento.
• Pagos: Stripe Checkout para inscripciones y suscripciones, con webhooks firmados. En el entorno de desarrollo la API se niega a arrancar con una clave de cobro real.
• Operación: Kubernetes sobre Google Cloud, en el mismo clúster en el que alojamos plataformas de clientes. Tareas programadas para el correo diario, la conciliación y las copias de seguridad.

Construido y operado con agentes, con red debajo

La velocidad sale de trabajar con agentes de IA. Un agente toma la siguiente tarea del plan, la implementa, pasa los controles, la prueba en un navegador y deja escrito qué ha hecho y por qué. La persona decide qué se construye y autoriza cada despliegue.

Lo que hace fiable ese ritmo son los controles. Hoy, 10 de octubre de 2026, la plataforma lleva 127 commits y estos controles se pasan antes de cerrar cada tarea:

• 72 pruebas de la API, contra una base de datos real.
• 98 pruebas de navegador con Playwright sobre la web construida, el correo y la API en local.
• 4 comprobaciones contra producción después de cada despliegue.
• Controles en la compilación de la web: si una página llevara texto del libro, la compilación falla.

Las pruebas también vigilan lo que el producto promete a sus usuarios: el diario y la autoevaluación se quedan en el navegador, y la analítica solo se carga cuando se aceptan las cookies. Una promesa con prueba automática se cumple en cada despliegue.

Lo que nos llevamos a los proyectos de clientes

• Primero algo funcionando en producción, luego lo demás. A mediodía ya había una web real en su dominio. Cada mejora posterior se desplegó encima de algo que ya funcionaba.
• Los controles van antes que la velocidad. Un agente escribe deprisa. Las pruebas son las que dicen si lo escrito sirve.
• Las copias de seguridad cuentan cuando se restauran. La de Kinbara se restauró el primer día.
• Operar es parte del producto. El correo diario, la conciliación de pagos y las copias corren solas en el clúster, y alguien las vigila.

Preguntas frecuentes

¿Cuánto se tardó, exactamente? El plan se guardó a las 10:49 del 23 de agosto de 2026 y el primer despliegue completo en producción es de las 12:30. El cobro con Stripe quedó en marcha a las 17:50. El contenido ya estaba escrito; la plataforma se construyó ese día.

¿Por qué Java y Spring Boot para algo así? Porque es lo que mejor conocemos y lo que más dura. Una API que cobra dinero tiene que ser fácil de probar y de mantener dentro de cinco años, y en eso Spring Boot es una apuesta segura.

¿Qué hacen los agentes y qué hace la persona? El agente implementa, prueba y documenta. La persona decide el qué, revisa y autoriza el despliegue. Los controles automáticos son el contrato entre los dos.

¿Dónde está alojado? En el clúster de Kubernetes que Arteco opera en Google Cloud, el mismo que usamos para plataformas de clientes. Con dominio propio, certificados, copias diarias y tareas programadas.

¿Podéis montar algo así para mi empresa? Sí. Es la forma de trabajar que aplicamos a los proyectos de clientes: arquitectura conocida, pruebas desde el primer día, despliegue automatizado y alguien que sigue cuidando la plataforma después.

Si quieres algo así para tu empresa

Llevamos desde 2012 construyendo y cuidando software a medida. Cuéntanos qué necesitas tener funcionando y te decimos qué parte puede estar en producción primero, con qué pruebas y quién la cuida después.

Escríbenos y lo vemos, o mira Kinbara en funcionamiento en kinbara.com.