14 dias, 105 sesiones, 1 CTO de IA: La historia completa de la construccion de sh0.dev

El 12 de marzo de 2026, comenzamos a construir una Plataforma-como-Servicio desde cero. Catorce dias despues, el 25 de marzo, teniamos un sistema de nivel produccion: 10 crates de Rust, 182 endpoints de API, 488 tests, 119 plantillas de un clic, 25 herramientas MCP para gestion asistida por IA, un panel completo en Svelte 5, un sitio web de marketing con procesamiento de pagos, y una CLI que replica cada accion del panel. El equipo de ingenieria total: un fundador humano en Abidjan, un CTO de IA.

Esta es la historia completa -- no el resumen de momentos destacados, sino el panorama completo. Lo que construimos, como lo construimos, que se rompio, que nos sorprendio y lo que aprendimos sobre el modelo CEO + CTO de IA que creemos transformara la forma en que se construyen las empresas de software.

La premisa

Juste Thales Gnimavo es el CEO de ZeroSuite, una empresa que construye seis productos desde Abidjan, Costa de Marfil. No es ingeniero. No escribe Rust, TypeScript ni SQL. Decide que construir, en que orden y con que restricciones. Define los requisitos del producto, revisa la salida y prueba los resultados. Es el experto del dominio, el gerente de producto y el departamento de QA.

Claude -- la IA que escribe este articulo junto a Thales -- sirve como el CTO. Las decisiones de arquitectura, implementacion, depuracion, auditorias de seguridad, documentacion y revision de codigo fluyen a traves de la IA. No como una herramienta de completado de codigo integrada en un IDE, sino como un socio basado en sesiones que mantiene contexto a traves de flujos de trabajo completos.

La relacion no es "desarrollador + copiloto". Es "CEO + CTO" -- uno establece la direccion, el otro ejecuta. La brecha entre esos dos modelos es toda la tesis de ZeroSuite.

La linea temporal

Dia 1 -- 12 de marzo: Fundacion (Fases 1-3, 15)

El scaffolding del proyecto fue la primera sesion. Un workspace de Cargo con 10 crates:

• sh0 -- el binario principal (CLI + servidor)
• sh0-api -- servidor API Axum
• sh0-db -- SQLite + migraciones + 22 archivos de modelo
• sh0-docker -- cliente de la API Docker Engine sobre socket Unix
• sh0-builder -- deteccion de stack + generacion de Dockerfile + salud del codigo
• sh0-proxy -- gestion de proceso Caddy + generacion de configuracion
• sh0-git -- git clone/pull + verificacion de webhook
• sh0-monitor -- recoleccion de metricas + evaluacion de alertas
• sh0-backup -- motor de respaldos + backends de almacenamiento
• sh0-auth -- Argon2 + JWT + TOTP + cifrado

Al final del Dia 1, teniamos el cliente del motor Docker (operaciones de contenedor, construccion de imagenes, gestion de red/volumen), el esqueleto del servidor API (CRUD de aplicaciones, activadores de despliegue, transmision de logs) y el cliente CLI (7 comandos). El conteo de tests era 256.

Dia 2 -- 13 de marzo: Pipeline de despliegue + correcciones de bugs

El pipeline de despliegue completo se consolido: git clone, deteccion de stack, generacion de Dockerfile, construccion de imagen Docker, creacion de contenedor con sondeo de salud, intercambio blue-green y actualizacion de ruta Caddy. La sesion de correccion de bugs abordo BUG-009 a BUG-012 -- repos git obsoletos, errores de permisos de Caddy, CSRF en POSTs sin cuerpo. Conteo de tests: 385.

Dia 3 -- 14 de marzo: Panel + pruebas en vivo

Tres sesiones paralelas. Las paginas principales del panel (aplicaciones, despliegues, logs, dominios, variables de entorno). Expansion del pipeline de despliegue (despliegue directo de imagen Docker, despliegue solo-Dockerfile, subida de archivo ZIP). Pruebas en vivo que revelaron BUG-014 a BUG-017 -- unicidad de nombres de aplicacion, limpieza de Docker, CSRF bloqueando subidas. Conteo de tests: 444.

Dia 4 -- 15 de marzo: Rediseno del panel + plantillas

La arquitectura del panel basada en stacks: barra lateral dual, barra lateral de contexto, paleta de comandos. La pagina Deploy Hub -- una interfaz de despliegue unificada estilo Softaculous con 183 opciones de despliegue. 119 plantillas YAML en 15 categorias (bases de datos, CMS, analitica, autenticacion, IA/ML, DevTools, productividad, email, colas, busqueda, redes, media, finanzas, educacion, foros). Terminal web via xterm.js y WebSocket.

Dia 5 -- 16 de marzo: Sitio web + pagos + almacenamiento

El sitio web de marketing (21 paginas). Integracion con Stripe para pagos globales. Integracion con ZeroFee para pagos Mobile Money en mas de 18 paises africanos. Proveedores de almacenamiento externo via OpenDAL (S3, R2, SFTP y 10 mas). Infraestructura del sistema de licencias. La pagina de documentacion de API con un playground en vivo.

Dia 6 -- 17 de marzo: Auditoria de seguridad + alineacion de precios

La primera auditoria de seguridad importante: 6 correcciones criticas (RBAC en almacenamiento, prevencion de inyeccion de shell, XSS, seguridad de token WebSocket, manejo de clave maestra), 8 correcciones altas, 4 correcciones medias. La sesion de alineacion de planes -- haciendo Free genuinamente generoso, moviendo terminal/cron/hooks/previews fuera de la restriccion Pro. Certificados SSL personalizados. Reglas de redireccion de URL. Autenticacion con cookies HTTP-only.

Dia 7 -- 18 de marzo: Pulido de infraestructura

URLs de conexion a base de datos y gestion de credenciales. Rediseno del editor de variables de entorno (clave-valor + editor raw .env). Gestion de claves SSH. Gestion de proveedores Git. Sistema de configuracion. Restauracion de respaldos desde almacenamiento externo. Rediseno de la pagina de monitoreo con 4 pestanas.

Dia 8 -- 19 de marzo: Correccion FTP/FTPS + pruebas de respaldo

La pesadilla FTP IPv6/EPSV. Evitamos OpenDAL para FTP/FTPS, escribimos un cliente suppaftp directo con modo EPSV y SNI TLS correcto. Probamos operaciones de respaldo de extremo a extremo.

Dia 9 -- 20 de marzo: Multi-servidor (Fase 29)

Soporte BYOS (Bring Your Own Server). Modulo de tunel SSH usando russh. DockerClient refactorizado en variantes Unix + TCP. Registro de nodos con monitoreo de salud. Transferencia de imagenes entre daemons Docker. Interfaz de asignacion de nodos en todos los formularios de despliegue.

Dia 10 -- 21 de marzo: Integracion OpenAPI

Integracion de utoipa 5: ToSchema en 69 DTOs, utoipa::path en 182 manejadores, especificacion OpenAPI 3.1 auto-generada servida en /openapi.json. Componente compartido ApiExplorer para documentacion + playground. Eliminamos las mas de 180 entradas de endpoints mantenidas manualmente. Dos pasadas de auditoria anadiendo documentacion de respuestas de error a los 182 endpoints. Conteo de tests: 478.

Dia 11 -- 22 de marzo: Aplicacion de licencias + MCP Fase 3

Aplicacion de licencias conectada en 10 archivos de manejadores, mas de 25 funciones restringidas. UpgradePrompt del panel integrado en todas las paginas restringidas. MCP Fase 3: operaciones de escritura, claves API con alcance, tokens de confirmacion de acciones destructivas. 25 herramientas MCP en total.

Dia 12 -- 23 de marzo: Asistente de IA

La interfaz de chat de IA en el panel. Gateway conectando a Claude via la API de Anthropic. Integracion de MCP Connector para uso directo de herramientas. Agentes especialistas (DevOps, DBA, Seguridad, Desarrollador, SRE, Red). Subidas de archivos e imagenes en el chat.

Dia 13 -- 24 de marzo: Sandbox de IA + busqueda web

Contenedor Sandbox de IA: un contenedor Alpine por aplicacion donde el asistente de IA puede ejecutar comandos, leer archivos, verificar conectividad y listar procesos. Herramientas de busqueda web y navegacion de URLs via Tavily y Jina. 27 herramientas MCP en total.

Dia 14 -- 25 de marzo: Pipeline de lanzamiento + pulido

Script de instalacion (curl -fsSL https://get.sh0.dev | bash). Compilacion cruzada para Linux x64/ARM64 + macOS. CI/CD con GitHub Actions. Auto-instalacion de Docker + Caddy en la primera ejecucion. Verificaciones de disponibilidad de puertos. El conteo final de tests: 488.

Los numeros

El stack

Backend: Rust. No porque Rust este de moda, sino porque un binario PaaS necesita ser un unico ejecutable enlazado estaticamente que funcione en bare metal sin un runtime. sh0 se compila en un binario que incluye el servidor API, el panel (integrado via include_dir), la CLI, el ejecutor de migraciones y el asistente de configuracion. Sin Python, sin Node.js, sin JVM en el servidor destino.

Frontend: Svelte 5 con runes ($state, $derived, $effect, $props). Compilado a archivos estaticos, integrado en el binario Rust, servido por Axum. TailwindCSS 4 para estilos. xterm.js para la terminal web. El panel es una SPA con adapter-static, lo que significa que produce una carpeta de HTML/JS/CSS que el servidor Rust sirve directamente.

Proxy inverso: Caddy. Gestionado programaticamente via su API de administracion. HTTPS automatico via Let's Encrypt. Balanceo de carga para escalado horizontal. Soporte de certificados SSL personalizados. Consideramos construir una capa de proxy en el binario Rust, pero la gestion de certificados de Caddy es madura y probada en batalla de maneras que habrian tomado meses replicar.

Base de datos: SQLite. Un archivo, cero configuracion, integrado en el proceso. Para un PaaS auto-alojado gestionando decenas a cientos de aplicaciones en un solo servidor, el rendimiento de SQLite es mas que suficiente, y la simplicidad operativa es insuperable. Sin cadenas de conexion, sin servidores de base de datos, sin coordinacion de respaldos -- solo un archivo que viaja con el binario.

IA: Claude via la API de Anthropic, con MCP (Model Context Protocol) para uso de herramientas. El asistente de IA en el panel puede listar aplicaciones, activar despliegues, leer logs, gestionar variables de entorno, ejecutar comandos en contenedores sandbox, buscar en la web y navegar URLs -- todo a traves de llamadas de herramientas estructuradas, no generacion de codigo libre.

La metodologia

Arquitectura de sesiones

Cada sesion de trabajo seguia un protocolo:

1. Registro de sesion creado con fecha, fase y objetivos
2. Implementacion -- escribir codigo, ejecutar tests, corregir problemas
3. Verificacion -- cargo build, cargo test, svelte-check, npm run build
4. Registro de sesion actualizado con lo que se hizo, archivos cambiados, conteos de tests y que sigue
5. Seguimiento de funcionalidades actualizado en FEATURES-TODO.md

Esto no es ceremonia por la ceremonia. Cuando estas ejecutando 105 sesiones en 14 dias, los registros de sesion son como mantienes la continuidad. Cada registro le dice a la siguiente sesion exactamente donde estan las cosas: que se construyo, que fallo, que necesita pruebas, que sigue. Sin ellos, el CTO de IA perderia contexto entre sesiones, y el CEO humano perderia el seguimiento del progreso.

Ciclos de auditoria

Cada 5-6 fases, ejecutamos una auditoria completa de seguridad y calidad. No una revision superficial -- un analisis sistematico de cada manejador, cada ruta de entrada, cada verificacion de privilegios. Las rondas de auditoria encontraron 88 problemas en total:

• Auditoria de Fases 7-12: 34 hallazgos (inyeccion de comandos, CSRF, CORS, limites de cuerpo, autenticacion WebSocket)
• Auditoria de Fases 13-19: 30 hallazgos (brechas de RBAC, SSRF, inyeccion HTML, inyeccion de cabeceras SMTP, path traversal en volumenes, bombas YAML)
• Auditoria de Fases 20-25: 51 hallazgos identificados, 37 corregidos (inyeccion de comandos en cron/hooks, bypass de autenticacion cross-app, validacion de URL, condiciones de carrera del autoescalador)
• Auditorias de Fase 29: 3 rondas de correcciones de seguridad multi-servidor (fallback silencioso a Docker local, limites de tamano de transferencia de imagenes, fugas de recursos de tunel SSH)

Los ciclos de auditoria detectaron problemas que ninguna cantidad de pruebas enfocadas en funcionalidades habria encontrado. SSRF en URLs de webhook. Inyeccion HTML en cuerpos de alertas por email. Inyeccion de cabeceras SMTP via saltos de linea en asuntos. Path traversal en montajes de volumenes compose. Estos son los bugs que generan titulares cuando llegan a produccion.

Agentes paralelos

Varias fases fueron disenadas para ejecutarse en paralelo usando git worktrees:

• Fase 11 (Motor de respaldos, Rust) junto a Fase 12 (Scaffolding del panel, Svelte) -- cero superposicion de archivos
• Fase 15 (Cliente CLI) junto a Fase 13 (Paginas principales del panel) -- ambos consumen la misma API, nunca tocan los mismos archivos
• Fase 16 (Plantillas) junto a Fase 14 (Paginas extendidas del panel)
• Fase 17 (Despacho de alertas) junto a Fase 18 (Docker Compose)

Este paralelismo fue posible porque la estructura de crates imponia limites limpios. El motor de respaldos vive en sh0-backup, el panel vive en dashboard/. Sin archivos compartidos significa sin conflictos de merge, y dos sesiones de agentes pueden trabajar simultaneamente.

Lo que no funciono

Compilacion cruzada

Lograr que el binario Rust se compilara cruzadamente para Linux ARM64 desde un host macOS fue un calvario de multiples sesiones. El crate aws-lc-sys (importado transitivamente por rustls) requeria CMake y perl en el contenedor de compilacion cruzada. Un bug de GCC causaba un fallo de optimizacion memcmp que requeria AWS_LC_SYS_CMAKE_BUILDER=1. Los helpers de credenciales Docker en macOS tenian problemas de PATH cuando se invocaban desde contenedores de compilacion cruzada. Finalmente forzamos todo el workspace a usar ring como proveedor de criptografia en lugar de aws-lc-sys, lo que elimino la dependencia de CMake por completo.

Caidas de Caddy

La gestion de procesos de Caddy fue mas fragil de lo esperado. El proceso de Caddy ocasionalmente moria sin salida de error -- terminado por el SO por presion de memoria, o fallando por una configuracion invalida que nuestra validacion deberia haber detectado. Anadimos un monitor de salud en segundo plano (intervalo de 5 segundos) que detecta cuando Caddy no responde y lo reinicia automaticamente. La secuencia de cierre graceful usa SIGTERM con timeout, luego SIGKILL como ultimo recurso.

FTP

FTP en 2026 no deberia ser tan dificil. La incompatibilidad IPv6/EPSV, la abstraccion de OpenDAL que no podia configurarse para el caso limite que encontramos, la discrepancia de hostname TLS SNI -- este unico protocolo consumio una sesion entera. Terminamos evitando la capa de abstraccion por completo y escribiendo un cliente directo. La leccion: cuando una abstraccion no puede manejar tu caso de uso, no luches contra la abstraccion. Reemplazala para ese caso de uso.

Alias de red Docker

Los despliegues de plantillas con aplicaciones multi-servicio (WordPress + MySQL, Ghost + MySQL, etc.) fallaban silenciosamente porque los contenedores Docker no eran alcanzables por sus nombres de servicio en la red. La correccion fueron dos lineas -- establecer el alias de red para que coincida con el nombre del servicio de la plantilla -- pero encontrar el bug requirio rastrear a traves del stack de red Docker para entender por que la resolucion de hostname fallaba dentro del contenedor.

Lo que nos sorprendio

El ritmo

Construir un PaaS en 14 dias suena absurdo. Es absurdo. Pero la metodologia basada en sesiones lo hizo posible. Cada sesion tenia un alcance claro (una fase, una auditoria, un lote de correcciones de bugs), criterios de verificacion claros (tests pasan, builds limpios) y un traspaso claro (registro de sesion con proximos pasos). El CTO de IA no se cansa, no pierde el foco despues de 8 horas y no necesita cambiar de contexto entre reuniones.

Lo que limita el ritmo es el humano. Thales reviso la salida de cada sesion, probo el panel manualmente, reporto bugs y decidio que construir a continuacion. La IA puede escribir codigo las 24 horas del dia, pero las decisiones de producto, las pruebas y el juicio de "esto realmente se siente bien cuando lo usas" son actividades fundamentalmente humanas.

Calidad de la auditoria de seguridad

Las auditorias de seguridad generadas por IA fueron mejores de lo esperado. No "buenas para una IA" -- genuinamente exhaustivas. La prevencion de SSRF en URLs de webhook, la correccion de inyeccion de cabeceras SMTP, la proteccion contra bombas YAML, la validacion de metacaracteres de shell en comandos cron -- estas no son vulnerabilidades de libro de texto que cualquier escaner detectaria. Requieren entender el contexto especifico de la aplicacion: que datos fluyen a traves de que manejadores, que entrada de usuario llega a que llamadas de sistema, donde estan los limites de confianza.

88 hallazgos de seguridad en 4 rondas de auditoria. Todos los problemas criticos y altos corregidos. Esa es una postura de seguridad que muchas startups con ingenieros de seguridad humanos no logran.

Registros de sesion como memoria institucional

Los registros de sesion resultaron ser mas valiosos de lo que esperabamos. No son solo un registro de lo que paso -- son la memoria institucional del proyecto. Cuando encontramos un bug en la sesion 80 que estaba relacionado con una decision tomada en la sesion 15, el registro de sesion de la sesion 15 explicaba por que se tomo esa decision, que alternativas se consideraron y que compromisos se aceptaron.

En un equipo tradicional, este conocimiento vive en las cabezas de los ingenieros y se pierde cuando se van. En el modelo de CTO de IA, vive en documentos estructurados que pueden ser leidos por cualquier sesion futura. Los registros de sesion son nuestra wiki de ingenieria, nuestro registro de decisiones y nuestro changelog, escritos en tiempo real mientras el trabajo ocurre.

El poder de la estructura sistematica

La estructura del workspace de Cargo con 10 crates no fue solo pulcritud organizacional -- fue lo que hizo posible toda la construccion. Limites limpios entre crates significaban sesiones de desarrollo paralelas. APIs publicas explicitas entre crates significaban que los cambios en un crate no se propagaban de forma impredecible. El sistema de migraciones significaba que los cambios de esquema de base de datos eran versionados y reproducibles. El panel integrado significaba que todo el producto se distribuia como un unico binario.

Cada decision estructural tomada en la primera sesion rindio dividendos en la ultima. La fundacion fue la inversion.

El futuro

sh0 no esta terminado. La plataforma principal funciona -- puedes instalarla con un comando curl, desplegar aplicaciones desde git, imagenes Docker, subidas ZIP o 119 plantillas, escalar horizontalmente, gestionar respaldos, monitorear tiempo activo y obtener operaciones asistidas por IA a traves del chat con MCP. Pero hay mas por construir:

• Fase 30: Diagnosticos de construccion con IA -- usando LLMs para explicar fallos de construccion en lenguaje sencillo
• Fase 31: Nixpacks/Buildpacks -- una ruta de construccion alternativa que no requiere Dockerfiles
• Fase 32: Multi-entorno (dev/staging/prod) con flujos de promocion
• Fase 33: GitHub Actions + proveedor Terraform
• Fase 36: SDKs de TypeScript, Python y Go

Y la version cloud -- sh0 gestionado con provisionamiento de servidores, despliegue multi-region y facturacion por solicitud -- es el siguiente hito importante.

La leccion

El modelo CEO + CTO de IA funciona. No en teoria, no como un experimento mental, sino en la practica, lanzando un PaaS de nivel produccion en 14 dias desde Abidjan con cero ingenieros humanos.

Pero funciona solo si lo haces bien. Las piezas que lo hacen funcionar no son glamurosas:

Disciplina de sesion. Cada sesion comienza con contexto, termina con un registro y tiene criterios de verificacion claros. Sin esto, el CTO de IA produce codigo que parece impresionante pero no se integra con lo que vino antes.

Auditorias sistematicas. La IA enviara vulnerabilidades de seguridad si no le pides que las busque. Los ciclos de auditoria -- programados, exhaustivos, documentados -- son lo que convierte "rapido" en "rapido y seguro".

Decisiones estructurales tempranas. El workspace de 10 crates, el sistema de migraciones, el panel integrado, el formato de registro de sesion -- estas fueron decisiones del Dia 1 que dieron forma a cada dia subsecuente. Si la estructura es incorrecta, la velocidad cae a medida que la complejidad crece. Si es correcta, la sesion 100 es tan productiva como la 10.

Un humano tomando las decisiones. La IA no sabe que construir a continuacion. No sabe si los precios son correctos para el mercado. No sabe si el panel se siente bien al usarlo. No sabe que los desarrolladores africanos necesitan soporte de Mobile Money, ni que un PaaS auto-alojado no deberia limitar a su propio administrador. El humano proporciona el juicio, el conocimiento del mercado y el gusto. La IA proporciona la ejecucion, la consistencia y la incansabilidad.

Un fundador. Un CTO de IA. Ciento cinco sesiones. Un producto.

Asi es como construimos sh0.dev.

Esta es la Parte 35 -- el articulo final de la serie "Como construimos sh0.dev". La serie completa cubre todo, desde el scaffolding del Dia 1 hasta las auditorias de seguridad, desde el motor Docker hasta el asistente de IA, desde el sistema de plantillas hasta los bugs FTP que casi nos destruyen. Si has seguido hasta aqui: gracias. Si quieres probar lo que construimos, la instalacion es un solo comando: curl -fsSL https://get.sh0.dev | bash.