4. Estado del Arte / Tecnologías Existentes

STATUS: borrador (v1) Estimación: 6-7 páginas

4.1 Soluciones similares existentes

El espacio de mercado donde se sitúa Quetzy ERP combina cinco categorías que históricamente han evolucionado por separado: comunicación de equipo, gestión de tickets, gestión documental y de contexto, comunicaciones en tiempo real (WebRTC) y gestión empresarial integral (ERP). Existen referentes consolidados en cada una de ellas, pero ninguna solución comercial integra los cinco frentes con el enfoque específico que requiere una consultora asistida por IA.

Comunicación y colaboración. Slack y Microsoft Teams dominan el segmento de chat empresarial. Discord, originalmente orientado al gaming, se ha colado en equipos técnicos por la calidad de sus llamadas de voz y la flexibilidad de sus servidores. Los tres son SaaS cerrados con coste por usuario y mes, sin opción real de auto-alojamiento ni control sobre los datos.

Gestión de tickets y proyectos. Linear se ha consolidado como referente en la última generación de herramientas de seguimiento, desplazando en muchos equipos a Jira por velocidad, claridad de UX y atajos de teclado. Trello, más antigua y simple, sigue siendo un estándar de facto del modelo Kanban por su pipeline visual de tarjetas. GitHub y GitLab incorporan también gestión de issues nativa que muchos equipos pequeños usan como su único sistema de tickets.

Gestión documental y de contexto. Notion y Confluence son las opciones por defecto en la mayoría de empresas para documentación interna. Obsidian ha emergido como alternativa local-first basada en archivos Markdown con enlaces internos, especialmente popular entre desarrolladores y equipos técnicos por su modelo de “second brain” descentralizado y sin dependencia de servidor.

Comunicaciones en tiempo real (WebRTC). Google Meet, Zoom y Microsoft Teams concentran el grueso del mercado. En el espacio open source, Jitsi Meet permite el auto-alojamiento completo de videoconferencias. LiveKit ha aparecido más recientemente como alternativa más ligera y orientada a desarrolladores que quieren integrar audio/vídeo dentro de su propia aplicación, con un modelo cliente-servidor abierto y SDKs en múltiples lenguajes.

ERPs comerciales y open source. Odoo y Dolibarr cubren el espacio clásico de ERP modular (facturación, inventario, RRHH, contabilidad), pero no están diseñados para el flujo de una consultora tecnológica moderna ni integran chat o llamadas como ciudadanos de primera clase del sistema.

Tooling agéntico para desarrollo. Más recientemente, una nueva categoría ha emergido: entornos de desarrollo agéntico. Claude Code (asistente conversacional con acceso al sistema de ficheros y herramientas), Codex y Gemini CLI son los referentes del lado cliente. Warp, terminal escrito en Rust con soporte nativo para múltiples agentes y orquestación cloud (Oz), se acaba de open-sourcear bajo AGPLv3+MIT en abril de 2026 y es el ejemplo más claro de un Agentic Development Environment (ADE) maduro. OpenCode es una alternativa TUI open source en la misma línea. Estos productos no compiten directamente con Quetzy, pero comparten su filosofía fundacional: el cuello de botella ya no es escribir código, sino las decisiones humanas (qué construir, validar el comportamiento, revisar) y para eso hace falta un buen sistema de contexto.

4.2 Comparativa de herramientas

La tabla siguiente resume la cobertura de cada referente sobre los cinco frentes que Quetzy unifica:

La conclusión es directa: ninguna solución existente integra los cinco frentes en un único sistema auto-alojable con un modelo de coste fijo predecible. Las consultoras pequeñas terminan pagando entre cinco y diez suscripciones SaaS distintas, sin control real sobre sus datos.

4.3 Justificación tecnológica

La elección de cada pieza del stack se hizo aplicando cuatro criterios: (1) self-hosting viable en un VPS modesto, (2) ecosistema activo y mantenido, (3) curva de aprendizaje razonable para un equipo pequeño y (4) compatibilidad con el flujo de desarrollo asistido por IA (código generable, contratos claros, testabilidad).

El proyecto se inspira explícitamente en cinco referentes para destilar patrones probados sin reinventar:

• Obsidian como modelo de capa de contexto. Su uso de enlaces internos entre notas Markdown demuestra que un sistema de contexto no necesita un GraphRAG complejo para ser útil a un LLM. Andrej Karpathy ha documentado que con unos cientos de notas bien enlazadas, un modelo navega el contenido sin necesidad de embeddings ni vector stores. Quetzy traslada esa intuición a context_items + entity_context_link (relación N:M), sin la superficie de ataque de los plugins de Obsidian (basados en Chromium).
• Claude Code como modelo de capa de agente. Se aprovechó la documentación pública aparecida durante 2025 sobre el manejo interno de contexto en herramientas agénticas para identificar patrones reutilizables, formalizándolos como estándar local del proyecto bajo el nombre context_items.
• Linear como referente de UX. Su densidad de información, atajos de teclado, vista lateral expandible y consistencia visual son el estándar de facto del sector.
• Trello como modelo de pipeline de tickets. La metáfora Kanban de tarjetas que cruzan estados es directamente trasladable a la máquina de estados de Quetzy, con la diferencia de que en Quetzy las transiciones son explícitas y validadas por guards funcionales en código.
• GitHub como modelo de versionado y gestión, con migración futura prevista a Forgejo (fork de Gitea, escrito en Go, mantenido por Codeberg e.V., GPLv3+) cuando el equipo crezca y se priorice la independencia de proveedor.

Durante la fase de investigación se evaluaron además herramientas del ecosistema agéntico moderno (DeerFlow, LangChain, LangGraph) para entender los patrones internos de los sistemas multi-agente. La decisión final fue no incorporarlas como dependencia y construir en su lugar interfaces propias mínimas (AIProvider, Skill<TInput, TOutput>), evitando el peso y el acoplamiento de esos frameworks en el código de producción.

4.4 Lenguajes

El sistema se desarrolla principalmente en TypeScript (versión 6.0.2 declarada en package.json), tanto en el frontend (React 19) como en los Route Handlers del backend de Next.js. La elección de TypeScript responde a tres factores: tipado estático que captura errores en tiempo de compilación, ecosistema masivo en el frente web, y compatibilidad excelente con asistentes de IA generativa, que producen código TypeScript con mucha mayor fiabilidad que en lenguajes con menos presencia en su corpus de entrenamiento.

Se utilizan adicionalmente JSX/TSX para los componentes de React, CSS puro para los estilos (a través de CSS Modules y CSS Custom Properties, sin Tailwind ni preprocesadores), SQL para el modelo de datos y consultas a PostgreSQL, YAML para Docker Compose y configuración de GitHub Actions, Bash para scripts de despliegue y Markdown para documentación interna y para la propia memoria del TFG, gestionada dentro del repositorio del proyecto.

4.5 Frameworks

Next.js 16.2.4 (con App Router y Turbopack) es el framework principal. Combina renderizado del servidor y del cliente en una única base de código TypeScript, expone Route Handlers para construir APIs REST sin necesidad de un backend separado e integra de serie las Server Actions para flujos de mutación como el inicio de sesión.

React 19.2.5 se utiliza como librería de interfaz, aprovechando hooks modernos, contextos compartidos y el modelo declarativo. Para componentes de interfaz accesibles, se usa Radix UI (@radix-ui/react-select).

En el lado servidor, Vitest 4.1.4 actúa como ejecutor de tests unitarios y de integración, con cobertura medida vía @vitest/coverage-v8. Para tests end-to-end se utiliza Playwright 1.59.1.

4.6 Librerías

• Insforge SDK 1.2.5 (@insforge/sdk): cliente unificado del backend (auth, base de datos, realtime, storage).
• livekit-client 2.18.9 y livekit-server-sdk 2.15.2: cliente browser y generación de tokens server-side para llamadas WebRTC.
• Zod 4.3.6: librería de validación y tipado en runtime, usada como capa de contrato compartida entre cliente y servidor (18 schemas).
• jose 6.2.3: verificación de JSON Web Tokens en el servidor, utilizada para validar la sesión del usuario contra el secreto JWT de Insforge.
• lucide-react 1.8.0: librería de iconos vectoriales.
• ESLint 9.39.4 + eslint-config-next: análisis estático de código.
• cross-env 10.1.0: gestión cross-platform de variables de entorno en scripts.

4.7 Bases de datos

PostgreSQL 15.15 sobre Debian es el motor de base de datos único del sistema. Está embebido en Insforge BaaS, lo que permite gestionar autenticación, base de datos relacional, capa de tiempo real (a través de triggers SQL que publican eventos vía WebSocket) y almacenamiento de archivos desde un único backend.

El modelo de datos lo definen 22 tablas: 20 declaradas en data_model.sql (versionadas en el repositorio) y 2 creadas directamente desde la consola de Insforge durante el desarrollo (time_entry y notification), pendientes de migración a data_model.sql como deuda explícita del proyecto.

PostgreSQL se elige frente a alternativas como MySQL, SQLite o bases de datos NoSQL por tres motivos concretos: soporte nativo para tipos como uuid y timestamptz que el sistema usa intensivamente, capacidad de definir triggers SQL (críticos para la capa de realtime de Quetzy) y madurez del ecosistema en herramientas de migración, observabilidad y backups.

4.8 Servicios cloud / hosting

El sistema no depende de servicios SaaS de terceros para ninguna pieza crítica. Todo está auto-alojado:

• Hosting: VPS en Hetzner Cloud (instancia CX33), proveedor europeo con buena relación calidad/precio y políticas de privacidad alineadas con el RGPD.
• DNS y registro de dominio: registrador externo, con apuntamiento A directo al VPS.
• TLS / certificados: Caddy gestiona la emisión y renovación automática de certificados Let’s Encrypt vía protocolo ACME, sin intervención manual.
• CI/CD: GitHub Actions ejecuta los pipelines de lint, test, build y despliegue. Es el único punto donde el sistema depende de un SaaS comercial; la migración futura a un runner propio sobre Forgejo + Woodpecker CI está documentada como deuda.
• Repositorio Git: GitHub (público, gratis), con migración futura prevista a Forgejo auto-alojado.

4.9 Hardware / infraestructura (si aplica)

El sistema completo se sirve desde un único VPS Hetzner CX33 con las siguientes características reales (verificadas vía SSH al servidor):

Sobre este VPS se ejecutan, en contenedores Docker gestionados por Docker Compose, los siguientes servicios:

• erp: la aplicación Next.js compilada en modo standalone (puerto interno 3000).
• livekit: servidor LiveKit v1.11.0 (puertos 7880, 7881/tcp, 50000-50100/udp).
• caddy: reverse proxy con TLS automático (puertos 80 y 443, TCP+UDP para HTTP/3).
• insforge-postgres-1 + componentes Insforge: backend de auth, base de datos, realtime y storage.

La elección de un VPS frente a soluciones serverless o PaaS se justifica por dos factores: coste fijo predecible (mensualidad cerrada, sin sorpresas por tráfico o por número de usuarios) y control completo sobre el sistema operativo, lo que permite depurar problemas de red, capacidades del kernel o ajustes de bajo nivel cuando sea necesario (por ejemplo, durante el diagnóstico del bug de audio asimétrico de LiveKit, fue posible inspeccionar logs detallados del servidor y reglas UFW directamente desde SSH).