Motory
ERP backend for inventory, orders, and customer management, built as Python microservices on PostgreSQL.
What it covers
Tech stack
The challenge
Inventory, orders, and customer records needed to live in one system instead of separate tools. The backend had to expose them as services other products could build on, on a data model that stayed consistent as modules were added.
Collaboration
I was a Python backend engineer at Motory. I built backend microservices and the ERP modules for inventory, orders, and customers, and designed the PostgreSQL models behind them.
From discovery to production
- Backend microservices in Python with FastAPI
- Django and Django REST Framework services on some projects
- ERP modules for inventory, orders, and customer management
- The PostgreSQL data models behind the ERP
How it was solved
The ERP is split into services by domain: inventory, orders, and customers. FastAPI serves the newer microservices, and Django with Django REST Framework covers projects that benefit from its admin and ORM. PostgreSQL is the shared source of truth, with relational models that tie an order to its stock and its customer.
Key technical decisions
- 01FastAPI for new microservices, for typed request models and a lightweight service footprint.
- 02Django and DRF where a project needed the admin and ORM out of the box.
- 03Relational PostgreSQL models, so orders, inventory, and customers stay consistent with each other.
Screenshots
Impact
- Inventory, orders, and customers are modules of one ERP instead of separate tools.
- Services are split by domain, so a module can change without touching the others.
- One relational model keeps stock, orders, and customer records in agreement.
What I learned
In an ERP, the data model is the product. Getting the relationships between orders, stock, and customers right in PostgreSQL mattered more than any single service.