12 de diciembre de 2025. Sesiones 006 a 019. Trece sesiones de desarrollo en un solo dia. De datos ficticios a llamadas API reales, de un diseno basico a un diseno inspirado en Stripe, de precios provisionales a un modelo de comision fija de 0,99%, de cero documentacion a mas de 90 endpoints completamente documentados.
Este fue el dia mas productivo en la historia de 0fee.dev, y posiblemente el dia individual mas productivo de desarrollo de software jamas documentado por un equipo CEO-IA.
El dia, sesion por sesion
Sesion 006: de datos ficticios a API real (~40 min)
El panel de control habia estado funcionando con datos ficticios desde la sesion 002. La sesion 006 lo conecto al backend real de FastAPI:
- Reemplazo todos los
mockTransactions,mockApps,mockProviderscon llamadas API - Implemento almacenamiento de token de autenticacion e inyeccion automatica de cabeceras
- Agrego estados de carga y manejo de errores para cada obtencion de datos
- Corrigio configuracion CORS para solicitudes de origen cruzado
Este fue el momento en que el panel dejo de ser una demo y empezo a ser una aplicacion real.
Sesion 007: flujo de checkout de prueba (~30 min)
Construyo el flujo de checkout de prueba de extremo a extremo:
- El proveedor de prueba acepta cualquier pago y devuelve exito despues de 2 segundos
- Widget de checkout conectado al proveedor de prueba para desarrollo
- Polling de estado de transaccion del widget al backend
- Estados de exito y falla con retroalimentacion de UI apropiada
Sesion 008: fusion de arquitectura (~45 min)
El sitio web de marketing era un proyecto separado del panel de control. Esta sesion los fusiono en una sola aplicacion SolidJS:
- Paginas de marketing en
/,/pricing,/docs,/about - Paginas del panel en
/dashboard/* - Componentes de diseno compartidos (cabecera, pie de pagina, tema)
- Pipeline de compilacion unico, despliegue unico
Sesion 009: correccion de localhost (~15 min)
La sesion mas corta. El frontend estaba haciendo llamadas API a localhost:8000, que funciona en desarrollo pero falla en cualquier otro lugar:
- Introdujo variable de entorno
VITE_API_URL - Actualizo todas las llamadas
fetch()para usar la URL base configurada - Agrego cambio de URL desarrollo/produccion
Quince minutos. A veces las sesiones mas importantes son las mas cortas.
Sesion 010: formato de pago unificado (~50 min)
Esta sesion introdujo la convencion de nombres PAYIN_ORANGE_CI:
- Prefijo de tipo de pago:
PAYIN_oPAYOUT_ - Identificador de proveedor/metodo:
ORANGE,STRIPE_CARD,MOMO - Sufijo de pais:
_CI,_SN,_KE - Mapeo cada metodo de pago soportado a este formato
- Actualizo el motor de enrutamiento para coincidir con cadenas de formato unificado
- Creo la matriz proveedor-metodo-pais
Sesion 011: paginas de checkout alojadas (~40 min)
Para comerciantes que no quieren incrustar el widget, paginas de checkout alojadas:
- URL dedicada por pago:
0fee.dev/pay/{payment_id} - Renderiza el mismo widget de checkout en un diseno de pagina completa
- Soporta personalizacion de marca (logo, colores, nombre)
- Redireccion post-pago a la URL de exito/falla del comerciante
- Generacion de codigo QR para la URL de pago
Sesion 012: analiticas del panel (~45 min)
La seccion de analiticas del panel:
- Graficos de volumen de transacciones diario, semanal, mensual
- Tasa de exito por proveedor
- Distribucion de metodos de pago (grafico circular)
- Ingresos por comisiones a lo largo del tiempo
- Conteo de apps activas y crecimiento
- Contador de transacciones pendientes en tiempo real
Sesion 013: el sistema de comision de 0,99% (~35 min)
El modelo de precios inicial:
- Starter: Gratis, 2% por transaccion, limite mensual de $10.000
- Growth: $49/mes, 1,5% por transaccion, limite mensual de $100.000
- Scale: $199/mes, 0,99% por transaccion, ilimitado
Esto duro exactamente tres sesiones.
Sesion 014: rediseno moderno de UI (~60 min)
La sesion mas larga del dia. Una revision visual completa:
- Navegacion lateral oscura con acentos de gradiente
- Diseno basado en tarjetas para secciones del panel
- Espaciado y escala tipografica consistente
- Logos de proveedores e iconos de metodos de pago
- Lineas limpias y espacio en blanco inspirados en Stripe
- Diseno responsivo para tableta y movil
- Bloques de fragmentos de codigo con resaltado de sintaxis
Sesion 015: correccion de precios -- la simplificacion (~20 min)
Tres sesiones despues de introducir el modelo de 3 niveles, fue eliminado:
- Elimino todo el codigo relacionado con niveles
- Comision unica: 0,99% por transaccion, sin cuotas mensuales
- Sin limites de volumen, sin restriccion de funcionalidades
- Cada usuario obtiene cada funcionalidad desde el primer dia
- Pagina de precios actualizada para reflejar el modelo de nivel unico
El razonamiento: los niveles crean friccion. Un desarrollador evaluando 0fee.dev no deberia necesitar comparar planes. Un precio, un conjunto de funcionalidades, cero decisiones.
Sesion 016: suspension de facturacion (~30 min)
Con el modelo de comisiones en su lugar, aplicacion de facturacion:
- Ciclo de facturacion mensual
- Balance negativo permitido (las comisiones se acumulan)
- Suspension en umbral de -$50
- Periodo de gracia: 7 dias despues del aviso de suspension
- API devuelve 402 Payment Required cuando esta suspendido
- Banner de advertencia en el panel a -$25
Sesion 017: monedas mundiales (~40 min)
Soporte de monedas expandido de 5 a mas de 25:
- Tabla de configuracion de monedas agregada
- Obtencion de tasas de cambio (via API externa)
- Formateo de montos consciente de la moneda
- El error
formatAmount(la contribucion duradera de la sesion 017) - Manejo de monedas sin decimales (XOF, JPY)
- Simbolos de moneda y mapa de configuracion regional de formateo
Sesion 018: cambio a httpx (~20 min)
Migracion de la libreria requests a httpx:
requestses sincrono, bloquea el bucle de eventos en FastAPIhttpxes nativo asincrono, compatible conasync/await- Todas las llamadas HTTP de adaptadores de proveedores convertidas
- Todas las llamadas de entrega de webhooks convertidas
- Pool de conexiones configurado para cliente asincrono
Sesion 019: documentacion completa de API (~50 min)
La sesion final de la maraton. Documentacion completa de API:
- Mas de 90 endpoints documentados
- Ejemplos de solicitud/respuesta para cada endpoint
- Documentacion del flujo de autenticacion
- Referencia de codigos de error
- Guias de inicio rapido de SDK para los 7 idiomas
- Referencia de eventos de webhook
- Documentacion de limitacion de tasa
El flujo del dia
Mirando las sesiones en secuencia, emerge un patron. El dia se movio a traves de cuatro fases:
Fase 1: Conectar (006-009) -- Conectar el frontend al backend. Corregir problemas de infraestructura. Fusionar proyectos separados en uno.
Fase 2: Estandarizar (010-012) -- Establecer el formato de pago unificado. Construir la alternativa de checkout alojado. Agregar analiticas.
Fase 3: Decidir (013-016) -- Tomar decisiones del modelo de negocio (precios, facturacion) e implementarlas inmediatamente. Iterar en horas, no semanas.
Fase 4: Expandir (017-019) -- Ampliar las capacidades de la plataforma (monedas, HTTP asincrono) y documentar todo.
Lo que hizo esto posible
Sin reuniones
No hubo reuniones diarias, ni sesiones de planificacion de sprint, ni juntas de revision de arquitectura. Thales decidia que construir a continuacion, y Claude lo construia. El ciclo de retroalimentacion se media en segundos, no en dias.
Sin retrasos de revision de codigo
En un equipo tradicional, los cambios de la sesion 006 pasarian por revision de codigo. Con preguntas, revisiones y disponibilidad del revisor, esa revision podria tomar un dia. Aqui, la "revision" era Thales probando la funcionalidad inmediatamente despues de que Claude generara el codigo.
Sin cambio de contexto
Claude mantuvo contexto completo a traves de las 13 sesiones. Las decisiones de arquitectura de la sesion 006 estaban completamente presentes en la sesion 019. No habia perdida de conocimiento entre sesiones, sin sobrecarga de "dejame releer el codigo".
Velocidad de decision de Thales
El factor mas subestimado. El modelo de precios fue introducido en la sesion 013 y reemplazado en la sesion 015 -- dos sesiones despues. En una organizacion tradicional, cambiar el modelo de precios requiere reuniones con producto, finanzas, marketing y liderazgo. Aqui, Thales decidio en minutos y Claude implemento en minutos.
El costo
Trece sesiones en un dia no es gratis. El costo fue:
Deuda tecnica. La velocidad produce atajos. El error de formatAmount (sesion 017) tomo hasta la sesion 066 para resolverse completamente -- 49 sesiones de efectos en cascada de una implementacion rapida.
Inconsistencias de diseno. El rediseno de UI de la sesion 014 fue exhaustivo, pero sesiones posteriores introdujeron componentes que no coincidian con el nuevo sistema de diseno. Estos se limpiaron en las sesiones 051 y 068.
Deriva de documentacion. La documentacion de la sesion 019 era completa en ese momento pero se volvio obsoleta a medida que las funcionalidades evolucionaron. El mantenimiento de la documentacion se convirtio en un costo continuo.
Por los numeros
| Metrica | Antes del 12 Dic | Despues del 12 Dic |
|---|---|---|
| Paginas frontend | 4 (datos ficticios) | 15+ (datos reales) |
| Integraciones API | 0 (simuladas) | API real completa |
| Metodos de pago | Teoricos | Flujo de prueba funcional |
| Modelo de precios | Ninguno | 0,99% fijo |
| Monedas | 3 | 25+ |
| Libreria HTTP | requests (sincrono) | httpx (asincrono) |
| Documentacion | Ninguna | 90+ endpoints |
| Proyectos | 3 separados | 1 unificado |
| Sesiones completadas | 5 | 19 |
En un dia, 0fee.dev paso de un prototipo con datos ficticios a una plataforma con funcionalidades completas con integracion API real, un modelo de precios, mas de 25 monedas y documentacion completa. Las sesiones despues del 12 de diciembre fueron sobre pulir, escalar y corregir lo que se construyo en este dia.
¿Lo hariamos de nuevo?
Si y no. La velocidad fue emocionante y el resultado fue transformador. Pero la deuda tecnica creada el 12 de diciembre tomo semanas para saldar. El enfoque ideal podria ser 7-8 sesiones por dia con 1-2 sesiones dedicadas a limpieza, en lugar de 13 sesiones de construccion pura.
Pero en el contexto de una startup corriendo al mercado desde Abiyan sin financiamiento y sin equipo, la maraton del 12 de diciembre fue la decision correcta. Enviar rapido, corregir despues, y asegurarse de que el "despues" realmente llegue.
Llego. Las sesiones 031 a 060 fueron el "despues".
Este articulo es parte de la serie "Como construimos 0fee.dev". 0fee.dev es un orquestador de pagos que cubre mas de 53 proveedores en mas de 200 paises, construido por Juste A. GNIMAVO y Claude desde Abiyan sin ningun ingeniero humano. Sigue la serie para conocer la historia completa de construccion.