MachParts.

Miles de repuestos en planillas Excel.

El cliente operaba con un catálogo de miles de repuestos mecánicos e industriales distribuido entre planillas Excel, archivos PDF de proveedores y conocimiento tácito en el equipo de bodega. Cada solicitud requería búsqueda manual cruzando referencias entre marcas, modelos y equivalencias.

Los efectos eran predecibles: tiempo perdido en búsquedas que escalaban con cada nuevo proveedor, errores de stock al no actualizar inventario en tiempo real, compras duplicadas por desconocimiento de equivalencias, y fricción operativa entre las áreas de mantenimiento y compras.

Probaron ERPs enlatados (SAP, Defontana, Manager) pero ninguno modelaba bien las equivalencias entre repuestos ni las órdenes de trabajo asociadas a equipos específicos. La operación industrial no encaja en el módulo de inventario genérico de un ERP estándar.

Un sistema construido para sus reglas.

Construimos un sistema empresarial completo con la arquitectura modelada en torno a repuestos, equivalencias, equipos, órdenes de trabajo y proveedores. No un ERP genérico forzado a su negocio: un sistema cuya base de datos refleja exactamente cómo opera el cliente.

22 módulos funcionales

Catálogo de repuestos con búsqueda multi-atributo. Equivalencias entre marcas. Kardex con movimientos en tiempo real. Órdenes de trabajo asociadas a equipos. Solicitudes de compra con aprobación multinivel. Recepción y despacho. Trazabilidad de números de serie. Reportería operativa. Gestión de proveedores. Importación masiva desde Excel. Roles y permisos granulares. Auditoría de cambios. Y más.

62 endpoints REST documentados

Backend FastAPI con OpenAPI/Swagger. Frontend React + TypeScript con tipos generados desde el contrato OpenAPI — cero drift entre backend y frontend. Tests automatizados sobre los endpoints críticos antes de cada deploy.

Diseño que el equipo adopta

UI optimizada para el flujo real: pantallas densas con atajos de teclado, búsqueda instantánea, atajos contextuales. La gente de bodega usa el sistema todo el día — la interfaz no puede ser una barrera.

Tecnología defendible.

Cada elección de stack tiene una razón operativa, no estética. Acá las cuatro decisiones clave:

Por qué FastAPI + MariaDB

FastAPI nos da OpenAPI gratis: el contrato de la API es la documentación viva. El frontend consume tipos generados automáticamente — refactor seguro. MariaDB porque el cliente ya tenía expertise SQL interno y backups en MySQL. Mantener su stack reduce dependencia de Bigcode y respeta su autonomía operativa.

Métricas defendibles.

Algunas son estructurales (verificables en repositorio), otras operativas (medidas con el cliente).

Tiempo de búsqueda: de minutos cruzando planillas a segundos con búsqueda multi-atributo. El equipo de bodega procesa más solicitudes con la misma dotación.

Errores de stock: eliminados al cargar movimientos en tiempo real desde el sistema. El kardex refleja la realidad física, no la última actualización mensual de la planilla.

Compras duplicadas: detectadas automáticamente por equivalencias. El sistema sugiere repuestos compatibles antes de generar una nueva orden de compra.

Lo que aprendimos.

Modelado de equivalencias es el problema real

El catálogo de repuestos suena simple hasta que aparecen las equivalencias: dos marcas distintas para el mismo componente, modelos descontinuados con sucesores parciales, repuestos que sirven para dos equipos pero con tolerancias diferentes. Modelar esto bien fue la mitad del proyecto — el resto fue UI.

OpenAPI como contrato viviente

Generar tipos TypeScript desde OpenAPI eliminó una clase entera de bugs (mismatch entre lo que envía el frontend y lo que espera el backend). Cuando cambias un schema, el compilador grita en el frontend antes de que el bug llegue a producción.

El cliente debe poder llevarse el sistema

Repositorio Git en infraestructura del cliente. Backups en su VPS. Documentación en su Notion. Si quisieran cambiar de proveedor de desarrollo mañana, podrían — el sistema es suyo, no nuestro.

Más trabajo en producción.