Órdenes de trabajo
Registro del vehículo, diagnóstico, repuestos, mano de obra y cierre, con historial por cliente.
Todos los proyectos
Case StudyEn producción
SGTT — Sistema de Gestión para Taller
Aplicación web que digitaliza la operación completa de un taller mecánico: órdenes de trabajo, inventario de repuestos, facturación y cuentas por cobrar, con control de usuarios y auditoría.
- Cliente
- Taller Tony
- Año
- 2026
- Rol
- Diseño, desarrollo y despliegue (proyecto individual)
- Stack
- React · Node.js · Express · SQLite · JWT · nginx · PM2
01
Overview
SGTT es un sistema web de gestión operativa construido para un taller mecánico que administraba su trabajo diario en cuadernos y hojas sueltas. El objetivo no era «hacer una app»: era ordenar la operación real del negocio sin obligar al equipo a cambiar su forma de trabajar de un día para otro.
El sistema cubre el ciclo completo de una orden de trabajo —recepción del vehículo, diagnóstico, repuestos utilizados, mano de obra, cierre y cobro— y mantiene el inventario y las cuentas por cobrar sincronizados con cada movimiento.
02
El problema
La información del taller vivía en papel y en la memoria del dueño. No existía forma confiable de saber cuánto se había facturado en el mes, qué repuestos quedaban en bodega o qué clientes tenían saldo pendiente.
Los errores más costosos no eran técnicos, sino de registro: repuestos entregados que nunca se cobraron, trabajos cerrados sin registrar y deudas que se olvidaban hasta que el cliente volvía meses después.
03
El reto
- El personal no tenía experiencia previa con software administrativo, así que cada pantalla debía ser autoexplicativa y tolerar errores de captura.
- El negocio necesitaba disponibilidad real: si el sistema se caía, el taller se detenía. Eso obligaba a un despliegue estable y con respaldos automáticos, no a una demo.
- Había que permitir correcciones sin destruir el historial: en un negocio real las facturas se equivocan, pero borrar registros elimina la evidencia de lo ocurrido.
04
La solución
Construí una aplicación web con un frontend en React y una API REST en Node.js/Express sobre SQLite, desplegada en un VPS propio con nginx como reverse proxy, HTTPS y PM2 para mantener el proceso vivo.
En lugar de permitir eliminaciones, el sistema usa anulación con auditoría: cada documento anulado conserva quién lo anuló, cuándo y por qué motivo. El historial nunca se pierde.
El comportamiento del sistema se ajusta con banderas de configuración en base de datos (por ejemplo, si se controla stock o si un trabajador puede anular documentos), de modo que el mismo código sirve para distintas reglas del negocio sin reprogramar.
05
Arquitectura
- Navegador — React SPA
- nginx — reverse proxy + HTTPS
- API REST — Node.js + Express (PM2)
- Lógica de negocio y validación
- SQLite (better-sqlite3) en disco persistente
- Respaldo automático nocturno vía cron
06
Tecnologías
| Tecnología | Función |
|---|---|
| React | Interfaz del panel administrativo y del flujo de órdenes |
| Node.js + Express | API REST, reglas de negocio y control de acceso |
| SQLite (better-sqlite3) | Persistencia local, rápida y sin servidor adicional |
| JWT + bcrypt | Autenticación por roles y almacenamiento seguro de contraseñas |
| nginx + Certbot | Reverse proxy, HTTPS y exposición del dominio |
| PM2 + cron | Proceso siempre activo, arranque en boot y respaldos nocturnos |
07
Funcionalidades
Inventario de repuestos
Entradas, salidas y descuento automático de stock al facturar, con control opcional por configuración.
Facturación y cuentas por cobrar
Documentos de venta, abonos parciales y seguimiento de saldos pendientes por cliente.
Usuarios y roles
Accesos diferenciados para administración y personal operativo, con permisos por acción.
Auditoría de anulaciones
Ningún registro con historial se elimina: se marca como anulado guardando usuario, fecha y motivo.
Respaldos automáticos
Copia nocturna de la base de datos con rotación automática de las versiones más antiguas.
08
Proceso de desarrollo
- 01
Research — Acompañé la operación del taller para entender el flujo real de una orden, no el flujo ideal.
- 02
Requirements — Definí qué debía registrarse obligatoriamente y qué podía quedar opcional para no frenar al usuario.
- 03
Architecture — Elegí un stack simple y autocontenido, priorizando que el sistema pudiera vivir en un solo servidor sin dependencias externas.
- 04
UI/UX — Pantallas con el vocabulario del taller, no el del programador: «orden», «repuesto», «abono».
- 05
Development — Iteraciones cortas con migraciones de base de datos no destructivas e idempotentes.
- 06
Testing — Scripts que firman un token válido y golpean la API real, verificando funciones completas y limpiando los datos de prueba al terminar.
- 07
Deployment — VPS con nginx, HTTPS, PM2 y respaldos programados; actualizaciones por git pull y reinicio controlado.
09
Decisiones y trade-offs
SQLite en lugar de PostgreSQL
Para un negocio de un solo local, con escrituras moderadas y un único servidor, SQLite elimina toda una capa de infraestructura sin costo funcional. El archivo vive en disco persistente y se respalda con un comando. Si el negocio creciera a varias sucursales concurrentes, migrar a PostgreSQL sería el siguiente paso natural.
Anular en vez de eliminar
Permitir borrado directo habría sido más rápido de implementar, pero destruye la trazabilidad contable. La anulación con motivo y responsable conserva la evidencia y hace que los errores sean auditables en lugar de invisibles.
Migraciones idempotentes en el código
En vez de una herramienta de migraciones externa, cada arranque verifica y agrega las columnas faltantes. Es una decisión deliberada de simplicidad: el despliegue se reduce a actualizar el repositorio y reiniciar, sin pasos manuales que se puedan olvidar.
Banderas de configuración en base de datos
Reglas como el control de stock o los permisos de anulación cambian según cómo trabaje el negocio. Guardarlas como configuración evita ramas de código paralelas y permite ajustar el comportamiento sin un nuevo despliegue.
10
Resultados
- El taller pasó de registros en papel a un sistema consultable: facturación, inventario y saldos pendientes dejaron de depender de la memoria.
- Las correcciones dejaron de ser un riesgo: toda anulación queda registrada con responsable y motivo.
- El sistema opera en un servidor propio con HTTPS, arranque automático y respaldo diario de la base de datos.
11
Qué aprendí
El mayor obstáculo de un sistema para un negocio real no es técnico, es de adopción. Las pantallas que hablan el idioma del usuario se usan; las que hablan el idioma del programador se abandonan.
La infraestructura simple gana cuando el equipo de mantenimiento es una sola persona: menos piezas significa menos formas de fallar a las 8 de la mañana.
Probar contra la API real con scripts fue más rentable que montar una suite de pruebas de interfaz: encontró errores de lógica de negocio con una fracción del esfuerzo.
Siguiente proyecto
Distribuidora de Huevos EscobarContacto
¿Construimos algo?
Estoy abierto a oportunidades profesionales, colaboraciones y proyectos donde la tecnología resuelva una necesidad concreta.