2. Introducción
STATUS: borrador (v1) Estimación: 4-5 páginas
2.1 Presentación del proyecto
Quetzy ERP es una aplicación web de gestión integral diseñada para consultoras tecnológicas que operan apoyándose en inteligencia artificial generativa. El sistema combina en una única plataforma la gestión de clientes y proyectos, un módulo de tickets con máquina de estados explícita, un chat con llamadas WebRTC integradas, control horario asociado a tareas, gestión de presencia del equipo y, como elemento diferencial, una capa de context_items pensada específicamente para que los modelos de lenguaje accedan a información validada por humanos en lugar de a contenido sin revisar.
El sistema se sirve bajo el dominio erp.quetzy.eu y está desplegado en infraestructura propia (VPS Hetzner CX33). Utiliza exclusivamente software self-hosted u open source para todas las piezas críticas: Insforge BaaS para autenticación, base de datos y realtime; LiveKit Server para señalización WebRTC; y Caddy como reverse proxy con TLS automático.
2.2 Motivación y origen de la idea
La motivación del proyecto combina una trayectoria técnica autodidacta y una observación profesional concreta.
Mi acercamiento a la programación comenzó de forma autodidacta durante la infancia, modelando lógica en sistemas reactivos basados en eventos y máquinas de estado. Esa práctica temprana facilitó que, al cursar el ciclo de Desarrollo de Aplicaciones Multiplataforma, los conceptos formales de programación se asimilaran rápido y permitiera dedicar el tiempo extra a explorar áreas paralelas: lenguajes de sistemas, ciberseguridad, robótica, ciencia de datos y gestión empresarial. A mediados del segundo curso del ciclo, contaba con más de veinte repositorios propios sobre proyectos en estos ámbitos.
El detonante específico de Quetzy llegó durante el periodo de prácticas en una consultora de proyectos web, ingeniería de datos (ETL/ELT), landings y marketing. Allí pude observar de cerca el cambio radical que la inteligencia artificial generativa estaba introduciendo en las consultoras: en sus workflows internos, en el criterio técnico que los clientes —tanto PYMES como grandes empresas— empezaban a esperar, y en la forma en que los equipos integraban la IA en su día a día. Resultaba evidente que reinventar modelos base (transformers) o sistemas agénticos no era una vía razonable para un proyecto académico, dada la velocidad con la que aparecen releases y proyectos open source en ese ámbito. La pregunta interesante no era qué modelo construir, sino cuál es la manera más óptima de gestionar productos digitales potenciando el desarrollo por IA sin desplazar el rol del programador, sino integrándolo en el flujo convencional de versionado y revisión por pares.
Esta pregunta se convierte en la tesis de investigación de este TFG: Quetzy no se construye como un ERP cualquiera, sino como una plataforma instrumental para responder a esa pregunta. El proyecto crece bajo necesidades reales detectadas durante el desarrollo (no bajo un listado cerrado de features) y aplica desde el día cero CI/CD automático, tickets transformados en planes de PRs, context_items como núcleo del contexto de negocio y un flujo Git altamente estandarizado pensado para escalar a equipos sin perder trazabilidad.
2.3 Contexto (problema detectado o necesidad)
Las consultoras tecnológicas pequeñas y medianas operan habitualmente con un ecosistema fragmentado de herramientas: Slack o Microsoft Teams para la comunicación interna, Jira o Linear para el seguimiento de tickets, Notion o Confluence para documentación, Google Meet o Zoom para llamadas, hojas de cálculo o software dedicado para el control horario, y soluciones puntuales para la gestión de clientes. Esta dispersión genera cuatro problemas concretos.
Primero, fricción operativa: un consultor pasa el día saltando entre cinco o seis aplicaciones, cada una con su propia interfaz, su propio sistema de notificaciones y su propia lógica de búsqueda.
Segundo, trazabilidad rota: una decisión técnica que se discute en una llamada, se documenta a medias en una herramienta y se ejecuta en un ticket de otra distinta pierde el hilo, y el contexto necesario para retomarla queda diluido entre tres herramientas distintas.
Tercero, y crítico en consultoras que apuestan por IA, alimentación deficiente de los modelos de lenguaje: los LLM no distinguen información validada de ruido. Si se les conecta a una documentación llena de borradores, ideas descartadas y notas obsoletas, generan respuestas pobres incluso siendo modelos de primer nivel. La calidad del contexto es hoy más determinante que la calidad del modelo.
Cuarto, un factor estructural: las soluciones SaaS comerciales que intentan unificar varios de estos flujos imponen un modelo de coste por usuario y mes que escala mal en equipos pequeños y obligan a entregar datos sensibles (conversaciones internas, contratos, contexto de cliente) a infraestructura de terceros.
A esto se suma un quinto factor más reciente y específico de la era post-2024: la asimetría entre la velocidad a la que la IA puede generar código y la velocidad a la que un equipo humano puede revisarlo, validarlo y mantenerlo. Sin un flujo Git estandarizado y un sistema de tickets que transforme tareas en planes ejecutables de PRs, la ganancia de productividad inicial se diluye en deuda técnica acumulada.
2.4 Objetivos generales y específicos
Objetivo general. Diseñar e implementar una plataforma web de gestión interna para consultoras tecnológicas asistidas por IA, que unifique en una sola aplicación los flujos de comunicación, gestión de proyectos, control horario y contexto técnico validado, y que sirva además como soporte experimental para responder a la pregunta de investigación planteada en la motivación: cómo integrar el desarrollo asistido por IA dentro del flujo convencional de versionado sin desplazar al programador.
Objetivos específicos:
- OE1. Implementar un sistema de chat en tiempo real con soporte para mensajes de texto, audio, adjuntos (imágenes y PDF), reacciones, indicadores de typing y embebido de tarjetas de proyecto.
- OE2. Integrar llamadas WebRTC con audio y compartición de pantalla mediante un servidor LiveKit autoalojado, con control de estado de la llamada en base de datos a través de webhooks.
- OE3. Desarrollar un sistema de tickets con máquina de estados explícita (14 estados) que separe cada fase del ciclo de vida de una tarea de consultoría y registre cada transición con su evidencia.
- OE4. Construir una capa de gestión de contexto técnico (
context_items) con flujo explícito de aprobación humana, distinción entre contexto crudo y contexto validado, y enlace N:M a entidades del ERP. - OE5. Aplicar una arquitectura limpia que separe contratos (Zod), interfaces de repositorio, implementaciones (mock + producción) y capa de presentación, garantizando testabilidad y permitiendo cambiar el backend sin reescribir el frontend.
- OE6. Desplegar el sistema en producción con CI/CD automático, TLS gestionado, y un mínimo del 80 % de cobertura de tests en el código de negocio.
- OE7. Reducir la dependencia de SaaS de terceros utilizando exclusivamente software self-hosted u open source para autenticación, base de datos, realtime y comunicaciones WebRTC.
- OE8. Validar empíricamente la metodología de ingeniería de contexto + tickets-como-planes-de-PRs mediante el desarrollo del propio ERP, midiendo si esta forma de trabajar es generalizable a equipos.
2.5 Metodología empleada
El proyecto se desarrolla íntegramente por una sola persona durante la mayor parte del ciclo de vida. Esta condición de equipo unipersonal no es un accidente, sino una decisión metodológica: permite controlar todas las variables de la metodología que se está validando y observar cómo escala (o no) cuando se integra a un segundo desarrollador.
En la fase final del proyecto se incorpora puntualmente un segundo desarrollador con la tarea explícita de lanzar Pull Requests siguiendo el flujo establecido, con el objetivo de validar empíricamente que la metodología de ingeniería de contexto, los estándares Git y la estructura de tickets-como-planes-de-PRs son extrapolables a un equipo. Esta integración funciona como prueba de concepto del OE8.
La metodología aplicada se apoya en los siguientes principios:
Desarrollo iterativo continuo, no por sprints fijos. Cada feature se aborda como una unidad cerrada con su propia rama, sus propios tests y su propia validación en producción antes de pasar a la siguiente. No hay ceremonias semanales ni plannings formales; el flujo es continuo y la unidad de iteración es la PR.
Ingeniería de contexto. Cada feature comienza con un prompt estructurado a un asistente de IA generativa (Claude Code) que incluye obligatoriamente: (1) investigación previa del repositorio (qué existe, qué archivos se tocan, qué convenciones aplican); (2) plan de commits atómicos numerados; (3) restricciones explícitas (qué NO tocar, qué patrones mantener); (4) criterios de validación post-deploy. La IA no escribe a ciegas: actúa como ingeniero de contexto que primero investiga y propone un plan que el humano aprueba antes de la implementación.
Tickets transformados en planes de PRs. Cada ticket del sistema no se cierra con una descripción y una asignación; se cierra con un plan de Pull Requests concreto, sus dependencias y los criterios de aceptación. Esto convierte la planificación en un artefacto ejecutable que reduce la ambigüedad cuando interviene la IA.
Estandarización Git. Convención de nombres de rama (tipo/scope-descripcion), Conventional Commits, squash and merge a main para mantener historial lineal, y CI/CD obligatorio (lint + test + build + deploy automático) antes de aceptar cualquier merge.
Tests por feature. Vitest para unitarios, con coverage objetivo del 80 % en el código de negocio. La validación end-to-end se hace en producción real, no en staging: el deploy automático se considera parte del flujo de validación.
Issues de feedback dentro del propio sistema. Las incidencias detectadas en uso se abren como issues en GitHub directamente desde el flujo de trabajo, evitando depender de herramientas externas. Esto es coherente con el principio fundacional del propio ERP.
context_items como núcleo de negocio. A diferencia de un ERP convencional que centraliza datos, Quetzy centraliza contexto validado: decisiones técnicas, justificaciones de arquitectura, restricciones de cliente, peculiaridades de cada proyecto. Este contexto es lo que se pasa a los modelos de lenguaje cuando intervienen en el desarrollo, y es lo que distingue al sistema de un gestor de información tradicional.
Asistencia continua de IA generativa, supervisada por humano. La IA participa en investigación, generación de planes, redacción de código y revisión, pero todas las decisiones arquitectónicas, todas las aprobaciones de PR y todos los merges los hace el humano. Esta separación de responsabilidades es justamente la que el OE8 busca validar.