El problema que originó Klion
Cuando trabajo en varios productos a la vez, las tareas, decisiones, worklogs y detalles de cada codebase tienden a quedar repartidos entre tableros, documentos, Git y conversaciones. Klion nació como un tablero para organizar trabajo freelance, pero el problema más importante terminó siendo conservar el contexto suficiente para volver a una tarea sin reconstruir todo desde cero.
Mi responsabilidad
Soy responsable del producto, la arquitectura y la implementación end-to-end. Construí la interfaz y el backend, modelé el flujo de proyectos y tareas, integré Git y desarrollé las superficies de CLI y MCP que conectan Klion con mis herramientas de trabajo.
Cómo evolucionó
Klion combina board de tareas, worklogs, proyectos, snapshots, base de conocimiento semántica, integración con Git, CLI y servidor MCP. La evolución fue incremental: primero hizo visible el trabajo pendiente; después empezó a conservar decisiones, contexto técnico y relaciones entre proyectos para que la herramienta también ayudara a investigar y ejecutar.
La arquitectura usa NestJS, Next.js, PostgreSQL con pgvector, MCP y Docker. La selección prioriza separar el dominio de trabajo, hacer consultable el conocimiento y mantener integraciones que puedan evolucionar sin convertir la herramienta en un flujo rígido.
Uso actual y límites de esta demostración
Lo uso diariamente como parte de mi forma de construir y operar software. El repositorio enlazado es una instantánea pública curada: sirve para mostrar el producto y algunas decisiones, pero no contiene todo el desarrollo privado ni el contexto de clientes y proyectos reales. Las capturas muestran datos de demostración y no deben interpretarse como una exposición del entorno operativo completo.