“No hay mejor forma de aprender que construir algo que se usará todos los días.” Esta frase ha cobrado sentido para mí desde que empecé a trabajar en el desarrollo de un ERP propio para FARAMAX. En esta entrada quiero compartirte los aprendizajes, errores y decisiones arquitectónicas que marcaron este proyecto full stack desarrollado con PHP 8 y React, y respaldado por MariaDB como base de datos relacional.
La idea inicial: de hojas de cálculo a un ERP real
El proyecto nació con un objetivo claro: dejar atrás los procesos manuales y descentralizados para unificarlos en un sistema integral y eficiente. No partimos de una plantilla ni de un sistema preexistente: había que construirlo desde cero, adaptado a los flujos reales del negocio.
La dificultad y, al mismo tiempo, el aprendizaje más profundo ha venido de esa libertad absoluta: sin ataduras, pero también sin red de seguridad.
Retos técnicos y organizativos que enfrentamos
1. Arquitectura modular y escalable
Desde el inicio, el enfoque fue construir el ERP como un conjunto de módulos independientes pero conectados: compras, ventas, almacén, facturación, recursos humanos… Cada uno con su propia lógica, sus vistas, y sus rutas API específicas.
Esto obligó a plantear una arquitectura limpia y extensible. Utilizamos controladores PHP que actúan como punto de entrada a los módulos y organizamos el código frontend en React en componentes reutilizables por dominio de negocio.
Lección: No subestimar la complejidad de orquestar múltiples módulos en un solo sistema. Un diseño desacoplado desde el principio evita deuda técnica futura.
2. Gestión de la lógica de negocio compleja
Conforme el ERP crecía, también lo hacían las reglas específicas del negocio. Por ejemplo:
- Validaciones encadenadas entre entidades (productos, stock, proveedores).
- Operaciones que modificaban múltiples tablas a la vez, con necesidad de transacciones SQL.
- Reglas condicionales según roles de usuario o tipo de operación.
Optamos por aplicar una capa de servicios en PHP que encapsula la lógica crítica, separando las operaciones puramente técnicas (como acceso a base de datos) del corazón del negocio.
3. MariaDB: el núcleo de los datos
Diseñamos la base de datos con normalización moderada, cuidando que las relaciones fueran claras pero sin penalizar el rendimiento en consultas frecuentes. Algunas decisiones clave:
- Uso extensivo de claves foráneas y restricciones para garantizar integridad.
- Vistas SQL para simplificar reportes sin duplicar lógica en PHP.
- Procedimientos almacenados solo para tareas muy repetitivas o sensibles al rendimiento.
Consejo: Diseña la base de datos pensando en cómo la vas a consultar, no solo en cómo se ve «bonita» en el diagrama.
4. React: usabilidad en un sistema denso
Uno de los mayores desafíos fue traducir operaciones densas en interfaces intuitivas. Usamos:
- React 19 con componentes funcionales y hooks (
useState,useEffect,useContext) para gestionar estado y contexto de usuario. - Formularios dinámicos con validaciones en tiempo real.
- Tablas interactivas con filtros y ordenación client-side.
- Comunicación con la API mediante
fetchencapsulado en hooks personalizados para estandarizar peticiones.
5. Adaptación continua a requisitos cambiantes
Como suele pasar en software interno, el proyecto fue creciendo y adaptándose constantemente:
- Cambios en los flujos de trabajo.
- Nuevas exigencias de reporting.
- Mejoras solicitadas por los usuarios tras comenzar a usarlo.
Esto nos obligó a escribir un código flexible y mantenible. En el backend, optamos por controladores RESTful agrupados por recurso. En el frontend, organizamos el estado global en contextos específicos por módulo, lo que facilitó integrar cambios sin reescribir grandes partes del sistema.
Reflexión final
Desarrollar un ERP a medida es una experiencia única que combina lo técnico con lo humano. Requiere entender profundamente tanto el lenguaje de programación como el del negocio. Cada decisión, desde el nombre de una tabla hasta cómo organizar un menú lateral, puede impactar directamente en la productividad de los usuarios.
Personalmente, este proyecto ha sido mi mejor escuela hasta la fecha. Me ha enseñado a planificar mejor, a anticipar problemas antes de que ocurran y a escribir software que no solo funcione, sino que se use con gusto.