From Spreadsheets to a Self-Hosted Mini-ERP: Building an Inventory System with an AI Layer

A full-stack developer in Venezuela built a self-hosted mini-ERP inventory system for a multi-warehouse company, replacing scattered spreadsheets with a single React Native + Expo client that compiles to Android and web. The system runs on a single self-hosted VPS managed with Coolify and includes an isolated Claude API layer for an admin chatbot, invoice vision reading, and product-rotation analysis that degrades gracefully if unavailable. It is now in daily use as the company's actual inventory system.

Inventory at the company I work for used to live in spreadsheets scattered across warehouses. Nobody could see another site's stock, shortages got caught too late, and goods sent out to events came back unreconciled. So I built a replacement — end to end, from the database to the server it runs on. This wasn't a greenfield side project with unlimited time. It had to ship, work for non-technical warehouse staff, and run on infrastructure I could maintain alone. That constraint killed a lot of "clean" ideas in favor of boring, reliable ones. Instead of a separate mobile app and web app, I built a single React Native + Expo client that compiles to both an Android APK and a static web export, with no duplicated code: bash same codebase, two artifacts eas build --platform android expo export --platform web Distribution skips app stores entirely — direct APK install, plus JS-only OTA updates through EAS Update, so warehouse staff get fixes without reinstalling anything. Multi-branch by design, not by accident Each warehouse "casa" manages its own inventory independently, with equivalences between boxes and loose units handled at the domain layer, not bolted on with if statements scattered across the codebase. A dedicated events module handles temporary dispatch — checklist out, automatic reconciliation on return. An AI layer that can fail without taking the app down I added a layer on the Claude API for three things: an admin chatbot, invoice reading through vision, and product-rotation analysis. The important design decision wasn't the AI part — it was isolating it so that a missing API key, a timeout, or a rate limit degrades that one feature gracefully instead of crashing the request pipeline. If the AI layer is unavailable, the core inventory system doesn't even notice. The migration nobody asks about until it's too late The system started on Vercel + Render + Supabase — fast to prototype, but three separate billing relationships and three separate points of failure for one internal tool. I migrated everything to a single self-hosted VPS managed with Coolify: containerized Postgres, own domain, Let's Encrypt SSL, zero downtime during the cutover. That's the unglamorous part of "full stack" that portfolios rarely show — not just writing the API, but being the one who gets paged if the server falls over. Where it landed - In daily use as the company's actual inventory system, not a demo. - Three services web, API, database collapsed into one Docker deployment. - Users get improvements over the air, without reinstalling. Full case study, architecture diagram and stack breakdown: https://www.gmarinelly.com/proyectos/inventario I'm a Full Stack developer and Computer Engineering student in Venezuela, open to remote roles. More projects including a truck-weighing system with real hardware integration at https://www.gmarinelly.com.