Responsibilities
Each component needs a clearly defined responsibility. Low coupling makes the system easier to evolve and reduces the impact of change.
Engineering Case Study
METRIFY CLOUD ERP
Software architecture for systems that cannot stop.
Over the past years I have designed the architecture, backend and infrastructure behind an ERP used every day by companies in northern Mexico. This project documents real software architecture, systems design and engineering decisions made in production.
The problem
I didn't start by building an ERP. I started by solving operations.
The goal was never to build a product. The goal was to build reliable software capable of evolving for years without interrupting the daily operation of multi-branch companies.
That required an architecture where availability, data consistency, performance, traceability, user experience and long-term maintainability were considered from day one.
Software Architecture
Architecture is not about avoiding change. It is about reducing the cost of change.
Building software used every day completely changed the way I design systems.
The priority stopped being writing more code. It became building an architecture capable of adapting to business growth without compromising stability, performance or availability.
Availability
When a company is selling, the architecture cannot become the bottleneck. Operational continuity shapes every technical decision.
Evolution
Business rules constantly change. Good architecture allows new capabilities to be added without breaking what already works.
Observability
Incidents are inevitable. The difference is the ability to detect, understand and solve them before they affect operations.
Integrations
SAT, payment gateways, APIs and external services will eventually fail, change behavior or become unavailable. Designing software for production means assuming that scenario from the beginning.
Data Model
Technologies change. Frameworks change. Languages change. Data remains. That is why the data model becomes one of the most important architectural decisions in the system.
Engineering Decisions
Building an ERP is not just about writing code.
It is about making technical decisions that keep a system reliable, maintainable and capable of evolving while business operations continue.
Over the years Metrify's architecture has evolved by incorporating new functional domains. Each one represents a different set of business rules, data models, integrations and engineering challenges.
Sales
Commercial workflows, quotations, orders, credit, invoicing and sales tracking.
Inventory
Stock control, movements, costing, traceability and branch synchronization.
Purchasing
Procurement, purchase orders, goods receiving and supplier management.
Electronic Invoicing
CFDI, SAT, cancellations, payment complements, stamping and fiscal integration.
Logistics
Delivery planning, routing, dispatch and shipment tracking.
Payments
Payment terminals, bank reconciliation, advances and different payment methods.
Integrations
REST APIs, Facturapi, NetPay, webhooks and external services.
Observability
Structured logging, auditing, monitoring, traceability and incident diagnosis.
Data Model
Relational design focused on consistency, performance and business evolution.
Infrastructure
Linux, Apache, PHP, JavaScript, MySQL, deployments and continuous operation.
Architecture
Modular backend, separation of responsibilities, maintainability and scalability.
User Experience
Interfaces designed to reduce operational errors and simplify daily work.
Engineering Stories
Real cases from production.
The sections above are decisions. These are the stories that explain why they became necessary.
Observability
The bug we never found
How a payment integration forced us to build observability, correlation and production diagnosis.
Read story →Architecture
More stories coming
Inventory, invoicing, auditing, webhooks, synchronization and architectural decisions born from operating real software.
Read story →A way of thinking
Architecture.
Not frameworks.
Engineering.
Not trends.
Software that keeps running years after it was written.