Proyecto educativo — no apto para producción sin validación técnica. Leer disclaimer
OVERVIEW
Los contratos están escritos para proteger a quien los redacta, no a quien los firma. El lenguaje legal es denso por diseño — lleno de cláusulas que pasas por alto cuando quieres cerrar un deal rápido. Freelancers que firman sin leer. Inquilinos que no entienden lo que están aceptando. Founders que no notan la cláusula de no competencia enterrada en la página 11.
Este proyecto te da el poder de cambiar eso: una app web donde subes cualquier contrato en PDF y la IA lo analiza en segundos. Te devuelve un resumen ejecutivo, identifica las cláusulas que merecen atención, detecta patrones de lenguaje desfavorables, y genera una lista de preguntas inteligentes para hacerle a un abogado antes de firmar.
No reemplaza al abogado — lo potencia. Y te da a ti, como parte que firma, la información para negociar desde una posición informada.
Técnicamente, es un proyecto que te hace dominar el manejo de archivos en Next.js, el procesamiento de texto largo, y el arte de diseñar prompts estructurados que devuelven outputs formateados y consistentes.
TECH STACK
THE PROBLEM
Hay una asimetría de información brutal en cada contrato que firmas. La parte que lo redacta tardó horas en construirlo con asesoría legal. Tú tienes 10 minutos para leerlo y la presión implícita de parecer razonable si preguntas demasiado.
Los servicios de revisión legal son caros y lentos. Las herramientas de IA genéricas pueden analizar texto, pero no están optimizadas para el contexto legal y no ofrecen una experiencia de usuario pensada para este caso de uso específico.
Existe un espacio enorme entre "fírmalo sin leer" y "contrata un abogado" — y este proyecto vive ahí.
PROPOSED SOLUTION
El flujo tiene tres etapas bien definidas:
Extracción: El usuario sube un PDF. Una API route en Next.js recibe el archivo con FormData, lo procesa con pdf-parse para extraer el texto plano, y limpia el output (eliminando headers/footers repetidos, normalizando espacios).
Análisis: El texto extraído se envía al modelo de IA con un prompt estructurado que pide un análisis en formato JSON con secciones predefinidas: resumen ejecutivo, cláusulas destacadas (con severidad: informativa / atención / riesgo), puntos fuertes del contrato, y preguntas sugeridas. El formato JSON garantiza que el output sea parseable y predecible.
Presentación: El frontend parsea el JSON y renderiza cada sección con componentes visuales distintos — colores por severidad, íconos, acordeones para las cláusulas largas. La experiencia final es más parecida a un informe de auditoría que a un dump de texto.
MVP FEATURES
RELEASE PHASE: v0.1-ALPHA// CÓMO EJECUTARLO
PASOS SUGERIDOS
Elegir la librería de extracción de PDF: Antes de instalar nada, pregúntale a tu agente cuál es la diferencia entre `pdf-parse` y `pdfjs-dist` para un proyecto en Next.js con Vercel. Evalúa los trade-offs (compatibilidad con Edge Runtime, dependencias de binarios, soporte de PDFs escaneados) y elige con criterio propio.
Construir y probar el pipeline de extracción primero: Antes de tocar la UI, construye el endpoint que recibe el PDF, extrae el texto y lo devuelve crudo. Pruébalo con tres contratos reales usando `curl` o Postman. Valida que el texto extraído es limpio y legible — si el PDF tiene headers repetidos o codificación rara, es el momento de limpiar el output.
Diseñar el schema del análisis antes de escribir el prompt: Define en TypeScript la interfaz exacta del JSON que quieres recibir del modelo. Ejemplo: `{ summary: string, clauses: Array<{ title, content, severity, explanation }>, questions: string[] }`. Este schema es tu contrato con el modelo — si lo cambias después, tienes que actualizar el prompt y el frontend al mismo tiempo.
Construir el prompt de análisis iterativamente: Pide a tu agente que genere un primer system prompt basado en tu schema. Luego pruébalo tú mismo con contratos reales y anota dónde el output no cumple el formato esperado. Itera el prompt hasta que el JSON sea parseable y consistente en al menos tres contratos distintos antes de avanzar.
Decidir la estrategia para contratos largos: Antes de integrar el análisis al flujo completo, evalúa con tu agente qué pasa si el contrato excede el context window del modelo. Discute las opciones: truncar con aviso al usuario, hacer chunking del texto, o limitar el tamaño de archivo aceptado. Elige una estrategia y refléjala en el código — no la dejes como caso sin manejar.
Integrar streaming para la respuesta: El análisis puede tardar 15-30 segundos para contratos medianos. Implementa streaming para mostrar progreso en lugar de una pantalla en blanco.
Construir y validar los componentes de resultado: Pide a tu agente que genere los componentes de visualización (resumen ejecutivo, lista de cláusulas con colores por severidad, preguntas sugeridas). Luego pruébalos tú con un JSON de ejemplo malformado — verifica que la app no rompe si el modelo devuelve un campo vacío o un tipo inesperado.
Cubrir los casos de error antes del deploy: Define con tu agente los mensajes de error para cada caso real: PDF escaneado sin texto extraíble, archivo demasiado grande, JSON inválido devuelto por el modelo, timeout. Cada error debe tener un mensaje específico y útil para el usuario — no un error genérico de JavaScript.
Deploy con variables de entorno correctas: Configura tu API key del proveedor de IA como variable de entorno en Vercel (`{{NOMBRE_DE_TU_VARIABLE, ej: OPENAI_API_KEY, ANTHROPIC_API_KEY}}`). Verifica que el límite de tamaño de payload de Vercel está configurado correctamente para manejar archivos PDF.
LO QUE VAS A APRENDER
Cómo evaluar trade-offs entre dependencias técnicas y elegir con criterio — no instalar la primera opción que aparece, sino entender qué implica cada una en producción
Diseñar el contrato de datos (schema TypeScript) antes de escribir el prompt — y por qué ese orden cambia completamente la calidad del output del modelo
Iterar prompts con casos reales hasta lograr consistencia — la diferencia entre un prompt que "funciona en el demo" y uno que funciona en producción
Definir una estrategia explícita para los casos límite (contratos muy largos, PDFs escaneados) antes de que se conviertan en bugs en producción
Validar que el sistema es robusto ante inputs inesperados — no solo que funciona con el caso feliz
Prompting para dominios especializados (legal, médico, financiero): cómo dar contexto al modelo sin hacerlo responsable de decisiones profesionales
HERRAMIENTAS
PUNTO DE PARTIDA SUGERIDO
Claude Code, Cursor o cualquier agente con soporte de proyectos
TAMBIÉN FUNCIONA CON
El método importa más que la herramienta. Elige la que ya conoces.
Seguridad
Nunca enviar datos sensibles del usuario directamente al LLM sin considerar qué información incluye el contrato — si el sistema es para uso propio está bien, pero si lo abres a otros usuarios, aclarar que los textos se envían a una API externa de IA
Validar el tipo MIME del archivo en el servidor, no solo en el cliente — un usuario puede renombrar cualquier archivo como `.pdf` para intentar subir contenido malicioso
Limitar el tamaño del archivo que se puede procesar tanto en el cliente como en la API route (Vercel tiene límites de payload — configura `export const config = { api: { bodyParser: false } }` y maneja el límite tú mismo)
No exponer la estructura interna del sistema en mensajes de error: un stack trace con rutas de archivo o nombres de variables internas es información útil para un atacante
Rendimiento
Implementar un límite de tamaño de archivo estricto antes de intentar extraer texto — procesar un PDF de 100MB puede agotar la memoria del servidor en Vercel
Truncar el texto extraído si supera el context window del modelo: contratos muy largos necesitan estrategia de chunking o al menos un aviso al usuario de que solo se analizará una parte
Paginar o colapsar los resultados si el análisis devuelve muchas cláusulas — mostrar 50 cláusulas expandidas al mismo tiempo degrada la experiencia y el rendimiento del DOM
Mostrar el análisis con streaming para que el usuario vea progreso en lugar de esperar 20-30 segundos con una pantalla en blanco
Arquitectura y Estructura
Separar la lógica de extracción de texto PDF de la lógica de análisis con IA: dos funciones o archivos distintos, cada uno con una única responsabilidad
Definir un schema TypeScript estricto para el JSON que esperas del LLM antes de escribir el prompt — el modelo debe cumplir ese contrato, y si no lo cumple, el parser debe fallar de forma controlada
Manejar el caso de PDFs escaneados (solo imágenes, sin texto extraíble) con un mensaje de error específico y útil, no un error genérico de JavaScript
Validar que el JSON devuelto por el LLM es parseable antes de intentar renderizarlo — un `JSON.parse` sin try/catch crashea toda la app
Antes de publicar (MVP Checklist)
Verificar que el límite de tamaño de archivo está implementado y muestra un mensaje claro al usuario antes de intentar el upload
Probar con un PDF corrupto o con un archivo `.jpg` renombrado como `.pdf` — la app debe mostrar un error amigable, no un stack trace
Confirmar que el output del LLM se valida antes de renderizar: si el modelo devuelve texto plano en lugar de JSON, la app no debe romper
Probar el prompt de análisis con al menos tres tipos de contrato distintos (arrendamiento, servicios, confidencialidad) — si el JSON devuelto varía en estructura, el prompt necesita más iteración antes de estar listo
Verificar que los datos del usuario (el texto del contrato) no se guardan en ningún log o base de datos del servidor si no es necesario
// FASES DE DESARROLLO
Fase 1 — Decisiones de arquitectura (2-3 días):
Evaluar y elegir la librería de extracción de PDF. Diseñar el schema TypeScript del análisis. Definir la estrategia para contratos largos. Estas decisiones estructuran todo lo que sigue — hacerlas mal al inicio cuesta más corregirlas después.
Fase 2 — Pipeline backend (4-5 días):
Endpoint de extracción de texto, integración con el modelo de IA, validación del JSON de respuesta. Probar con al menos tres contratos reales e iterar el prompt hasta que el output sea consistente antes de avanzar a la UI.
Fase 3 — Interfaz y flujo completo (4-5 días):
Componente de upload con drag-and-drop y estados (esperando → procesando → resultado → error). Integrar streaming para mostrar progreso. Validar que la UI maneja correctamente un JSON malformado o una respuesta de error del backend.
Fase 4 — Robustez y edge cases (3-4 días):
Cubrir los casos que rompen la app en producción: PDF escaneado sin texto, archivo demasiado grande, timeout del modelo, JSON inválido. Cada error con un mensaje específico y útil para el usuario.
Fase 5 — Deploy y revisión final (1-2 días):
Configurar variables de entorno en Vercel, verificar límites de payload, correr el checklist de buenas prácticas antes de publicar.
¿Agente o modo chat?
Modo agente para las Fases 1-2. Una vez que el backend funciona, puedes cambiar a modo chat para iterar sobre la UI y los prompts de análisis — son cambios más puntuales.
¿TUI o editor?
Claude Code (TUI): Ideal para generar el proyecto base, el endpoint de procesamiento y manejar múltiples archivos a la vez.
Cursor o Windsurf (IDE): Útiles para refinar los prompts de análisis dentro del código — puedes editar el system prompt directamente y ver los cambios en contexto.
GitHub Copilot: Adecuado para completar código repetitivo (manejo de errores, validaciones de schema) una vez que la estructura principal está definida.
// PROMPT INICIAL SUGERIDO
Voy a construir una app web en Next.js que analiza contratos en PDF usando un modelo de IA.
Antes de escribir código, necesito que me ayudes a tomar dos decisiones de arquitectura:
1. Librería de extracción de PDF: evalúa `pdf-parse` vs `pdfjs-dist` para un proyecto
en Next.js desplegado en Vercel. Considera compatibilidad con el App Router, Edge Runtime,
dependencias de binarios, y soporte de PDFs escaneados. Recomiéndame una y explica
por qué descartaste la otra.
2. Estrategia para contratos largos: ¿qué hacemos si el texto extraído supera el context
window del modelo? Dame tres opciones con sus trade-offs (truncar, chunking, límite de
archivo) y dime cuál recomendarías para un MVP.
Una vez que hayamos decidido eso, construye el endpoint de extracción y análisis con este schema
de respuesta:
{{pega aquí tu schema TypeScript, ej:
{
summary: string,
clauses: Array<{ title: string, content: string, severity: "info" | "warning" | "risk", explanation: string }>,
questions: string[]
}
}}
El endpoint debe:
- Recibir el PDF como multipart/form-data
- Extraer el texto con la librería que elijamos
- Enviar el texto al modelo con un system prompt de análisis legal
- Validar que el JSON devuelto cumple el schema antes de responder al frontend
- Manejar errores específicos: PDF sin texto extraíble, archivo demasiado grande, JSON inválido
Explica cada decisión de implementación que tomes, especialmente si hay trade-offs.¿LISTO PARA CONSTRUIRLO?
Abre tu herramienta de Vibe Coding favorita y empieza a construir.