Tres proyectos, tres formas distintas de romperme la cabeza

Giusseppe Marinelly — Tue, 15 Sep 2026 18:45:02 +0000

Publicado originalmente en mi blog.

Soy estudiante de Ingeniería en Computación y desarrollador. Este año construí tres cosas muy distintas entre sí, y cada una me obligó a desaprender algo. Las dejo aquí porque los problemas interesantes no siempre fueron los que esperaba.

1. Leer una báscula industrial por puerto serie

El encargo era sustituir el software de pesaje de camiones de una planta. Yo venía de desarrollo web, así que mi primer instinto fue pedir el peso cuando lo necesitara, como una petición HTTP.

No funciona así. Una báscula no expone una API: emite tramas continuas por el puerto serie, sin que se las pidas y a su propio ritmo. El flujo manda, y hay que escucharlo.

Eso definió la arquitectura: un proceso leyendo el puerto de forma continua, un backend en FastAPI que retransmite por WebSocket, y dos estaciones de escritorio viendo el mismo peso en el mismo instante.

Pero el reto de verdad no fue el hardware. Fue el modelo de estados. Un pesaje pasa por en_planta → pendiente_aprobacion → aprobado/rechazado → completado, y un registro completado no se puede tocar: es un documento con consecuencias contables. Diseñé el esquema asumiendo que alguien va a intentar editarlo y que la respuesta correcta del sistema es impedirlo.

Catorce tablas en PostgreSQL, migraciones con Alembic y pruebas con Pytest sobre SQLite aislado. Esto último no fue opcional: cuando un bug cambia un peso facturable, no te enteras en desarrollo, te enteras en una factura.

Lo que aprendí: integrar hardware te quita suposiciones que en web das por hechas. Que los datos llegan cuando los pides. Que puedes reintentar. Que el estado vive en tu base.

2. Epa: una app social donde el problema era la privacidad

Epa es una app móvil para que los estudiantes de mi universidad organicen planes en el campus: mapa de actividades, grupos y mensajería, con acceso cerrado por correo institucional.

Suena a CRUD. No lo es, porque dos funciones inocentes resultaron delicadas:

Ubicación. Mostrar dónde está la gente es útil y también es vigilancia. La resolví como opt-in con caducidad automática: compartes tu ubicación por un rato y expira sola. Nadie tiene que acordarse de apagarla.

Media efímera. "Efímero" en el cliente no significa nada: cualquiera intercepta la petición. La entrega de archivos la controla el servidor, no la app.

Stack: React Native con Expo, TypeScript, Expo Router, NativeWind y Zustand del lado del cliente; Express, Prisma y PostgreSQL del lado del servidor.

Lo que aprendí: en una app social, las decisiones difíciles casi nunca son técnicas. Son sobre qué le permites hacer a un usuario con los datos de otro.

3. BeatWave: una PWA de música que funciona sin internet

Tenía mi música en un servidor Navidrome propio y quería escucharla en el teléfono sin depender de una app de terceros. Así salió BeatWave: una PWA instalable que consume la API Subsonic de mi servidor.

La parte divertida fue el offline. Guardar pistas en IndexedDB y servirlas desde un service worker es directo en teoría; en la práctica el trabajo está en decidir qué pasa cuando la red vuelve a medias, cuando el caché y el servidor no coinciden, o cuando el usuario cierra la app a mitad de descarga.

También integré la Media Session API, que es de esas cosas que casi nadie nota y todos esperan: controles en la pantalla de bloqueo, con carátula y título. Cuando falta, la app se siente rota aunque funcione.

Stack: React 19, TypeScript, Vite y vite-plugin-pwa.

Lo que aprendí: offline-first no es "cachear cosas". Es aceptar que tu app va a vivir permanentemente en un estado intermedio entre conectada y desconectada.

Lo que tienen en común

Que en los tres el problema real estaba en otro lado del que yo pensaba. En el primero creí que era el hardware y era el modelo de datos. En el segundo creí que era el mapa y era la privacidad. En el tercero creí que era el reproductor y era la sincronización.

Escribo sobre lo que construyo en gmarinelly.com, y el código está en GitHub.

Si trabajas con integración de hardware, offline-first o apps móviles, me interesa mucho leer cómo lo resolviste tú.

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

Giusseppe Marinelly — Tue, 15 Sep 2026 18:31:04 +0000

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.

The constraint that shaped everything

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.

One client, two targets

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.

DEV Community: Giusseppe Marinelly