IGOMS
Multi-tenant operations platform for independent auto garages
One deployment serves many garages, with work orders, parts requests, inventory and customer vehicle histories separated by tenant.
Decision
Isolation is enforced in the API service layer, where tenant context is resolved once at the boundary rather than in each handler.
Why
That is what makes it viable for one developer to run as a product.
Cost
A query missing its filter would expose one garage's data to a competitor.
Decision
Stock is currently a single computed value that approved part requests decrement and stock-ins increment.
Why
It answers the only question a mechanic asks.
Cost
It keeps no history, so "who took the last one and when" has no answer and two approvals landing together can read the same count. It is being replaced with append-only movement rows, where current stock is derived rather than stored.
Decision
MongoDB was chosen.
Why
The data model was still changing weekly and a schemaless store meant no migration on every iteration.
Cost
It is the wrong fit for what this became. A system that issues parts against work orders needs writes that all succeed or all fail, and a product sold to competing businesses wants isolation the database enforces. A PostgreSQL migration is planned, with the data model changing before the database does.
The hardest problem was modelling multi-tenancy in the service layer, and keeping that structure correct as the number of endpoints grew.
Interface available in English and Amharic.
Stack
- React: Component architecture for the dashboard and work-order workflows.
- TypeScript: Type safety across multi-tenant payloads and API contracts.
- Node: Runtime for the API service layer.
- Express: Routing and boundary middleware for tenant resolution.
- MongoDB: Initial store during rapid data-model iteration; PostgreSQL migration planned.
- Recharts: Operational charts for garage owners.
Screens
