ULTRA ERP ULTRA ERP

Contexto Context

SupleYA es un comercio de suplementos donde trabajé en la operación diaria — ventas, atención al cliente y contabilidad. Estar adentro de la operación me permitió ver de primera mano dónde se perdía tiempo y dónde faltaba información para decidir. De ese relevamiento funcional nació ULTRA ERP. SupleYA is a supplements retailer where I worked in day-to-day operations — sales, customer service, and accounting. Being inside the operation let me see firsthand where time was lost and where information was missing to make decisions. ULTRA ERP grew out of that functional analysis.

Problema Problem

La gestión estaba repartida entre planillas y procesos manuales: stock, ventas, compras y caja vivían en lugares separados. Consultar algo tan simple como el stock disponible de un producto tomaba minutos, y no había una vista unificada para entender el estado del negocio ni para apoyar las decisiones del día a día. Management was scattered across spreadsheets and manual processes: stock, sales, purchases, and cash lived in separate places. Answering something as simple as the available stock of a product took minutes, and there was no unified view to understand the state of the business or support day-to-day decisions.

Solución y decisiones técnicas Solution and technical decisions

• → ERP modular con Next.js y Supabase (Auth, Postgres y RLS). Elegí RLS para resolver el acceso por rol directo en la base, sin reimplementar permisos en cada endpoint.
• → Asistente con RAG: usé pgvector para indexar el contexto del negocio como embeddings y Gemini 2.0 Flash como modelo. La decisión de fondo fue que el dueño pudiera preguntar en lenguaje natural ("¿cuánto stock me queda de X?") sin saber SQL ni navegar reportes.
• → Generador de posts para redes sociales con IA, para sacar el marketing del terreno manual.
• → Dashboards con shadcn/ui y Recharts, y reportes exportables con React PDF.
• → Suite de tests con Vitest, Testing Library y pruebas end-to-end.

• → Modular ERP with Next.js and Supabase (Auth, Postgres, and RLS). I chose RLS to handle role-based access directly in the database, instead of re-implementing permissions on every endpoint.
• → RAG assistant: I used pgvector to index the business context as embeddings and Gemini 2.0 Flash as the model. The core decision was letting the owner ask in natural language ("how much stock of X do I have left?") without knowing SQL or navigating reports.
• → AI-powered social media post generator, to move marketing out of manual work.
• → Dashboards with shadcn/ui and Recharts, and exportable reports with React PDF.
• → Test suite with Vitest, Testing Library, and end-to-end tests.

La restricción que definió el diseño The constraint that shaped the design

El pedido del dueño incluía una condición que parecía menor y terminó ordenando toda la arquitectura: sin costos mensuales de infraestructura. Eso descartó contratar una base vectorial aparte para el asistente, así que los embeddings viven en el mismo Postgres del ERP con la extensión de vectores; y descartó los modelos pagos, así que la capa de IA se armó sobre APIs con capa gratuita. La restricción de presupuesto no achicó el proyecto: lo obligó a ser más simple, con una base menos que mantener. The owner brief included a condition that looked minor and ended up organising the whole architecture: no monthly infrastructure costs. That ruled out paying for a separate vector database for the assistant, so the embeddings live in the ERP own Postgres with the vector extension; and it ruled out paid models, so the AI layer was built on free-tier APIs. The budget constraint did not shrink the project: it forced it to be simpler, with one less database to maintain.

De dónde salieron los requisitos Where the requirements came from

El relevamiento no fue una reunión: fue un cuestionario escrito que el dueño completó sobre cómo funciona su negocio de verdad — situación fiscal, cómo carga precios, cómo maneja proveedores, qué mira para decidir. Trabajar adentro del local me dio la intuición, pero el documento es lo que evitó que construyera lo que yo suponía en vez de lo que él necesitaba. Discovery was not a meeting: it was a written questionnaire the owner filled in about how his business actually works — tax situation, how he loads prices, how he handles suppliers, what he looks at to decide. Working inside the shop gave me the intuition, but the document is what kept me from building what I assumed instead of what he needed.

Mi rol My role

Desarrollo end-to-end: hice el relevamiento funcional, definí la arquitectura, construí el frontend y el backend, integré la capa de IA (RAG) y me ocupé del deploy. Traducir las necesidades operativas que ya conocía a features concretas fue la parte que más diferencia hizo. End-to-end development: I did the functional analysis, defined the architecture, built the frontend and backend, integrated the AI layer (RAG), and handled the deployment. Translating the operational needs I already knew into concrete features is what made the biggest difference.

Resultado Result

Las consultas de stock pasaron de minutos a segundos y la operación quedó centralizada en un solo lugar. El asistente de IA convirtió preguntas de negocio en respuestas inmediatas, sin pasar por planillas. Stock queries went from minutes to seconds and the operation was centralized in one place. The AI assistant turned business questions into immediate answers, with no spreadsheets in between.

Aprendizajes Learnings

• → Diseñar un RAG útil sobre datos de un negocio real: qué indexar y cómo darle contexto al modelo.
• → Modelar permisos multi-rol con RLS en Postgres en lugar de en la aplicación.
• → El mayor valor técnico vino de entender el dominio antes de escribir código.

• → Designing a useful RAG over a real business’s data: what to index and how to give the model context.
• → Modeling multi-role permissions with RLS in Postgres instead of in the application.
• → The biggest technical value came from understanding the domain before writing code.