Aviation Parts & MRO — a Custom Operations Platform
For an aviation spare-parts trading and repair company, I designed and built the operations platform itself — inventory, procurement, repair orders and the books — running on code I wrote from the database up, not on Odoo.
This is not an Odoo implementation. It's a fully custom, full-stack build — a Node.js/Express API on PostgreSQL, with a React front end — because this business's combination of parts trading and in-house repair needed a data model no off-the-shelf package, Odoo included, was going to fit without being bent out of shape. I'm including it here, under Solutions, because it's the clearest example of what I do when the right answer isn't an ERP at all.
The challenge
This client runs two businesses under one roof: trading aviation spare parts — buying and reselling parts in varying condition — and repairing and overhauling parts for other operators. Both sides pull on the same physical inventory in different directions. A part on the shelf might be for sale as-is, or it might be a core waiting to go out for overhaul and come back sellable at a different condition and a different price. Every part also carries aviation-specific state a generic "product" record was never built to hold: a condition code, an ATA chapter, a lot or serial number it has to stay attached to for life, and a flag for whether the paperwork proving where it came from is actually on file.
None of that is exotic on its own — plenty of systems do inventory, plenty do procurement, plenty do accounting. What's hard is the combination: trading and repair sharing one inventory, procurement decisions made by comparing vendor quotes before a purchase order exists, a repair order that has to know which parts, which vendor and how long it's been out, and a set of books that reconciles to all of it without a nightly export to a separate accounting package. Rather than reshape an existing system's data model around that — Odoo included, which is what I use for the large majority of my implementations — I designed the schema and workflow from scratch and built the platform to match how this business actually runs, not how a generic package assumes it runs.
What I built
Seven pieces, all in one PostgreSQL schema and one React app — not a warehouse tool bolted to an accounting tool bolted to a spreadsheet:
Multi-Warehouse Inventory With Lot & Serial Traceability
Stock is tracked by warehouse and location, down to the individual lot or serial number, so every part can be traced through every movement it's had — receipt, transfer, repair, sale — instead of just a quantity on hand. That traceability chain is the backbone everything else in the platform hangs off.
Parts-Condition Coding & ATA Classification
Every part carries the condition codes the industry actually trades on — New, Overhauled, Serviceable and As-Removed — plus an ATA-chapter classification, the standard system for categorising aircraft parts by system, and a certificate/traceability flag showing whether the supporting paperwork is on file. These sit as core fields on the part record, not as custom fields tacked onto a generic product form.
Vendor-Quote Comparison to Purchase Order to Goods Receipt
Buyers log quotes from multiple vendors for the same part, compare them side by side, and convert the one they choose straight into a purchase order. Goods receipt then reconciles what actually arrives — quantity and condition — against what was ordered, before anything is accepted into stock.
Repair-Order (MRO) Tracking
A repair order links the part, the vendor or shop doing the work, and the turnaround, so the team can see at a glance what's out for repair, where it's sitting, and for how long — instead of tracking it by phone calls and a spreadsheet running alongside the "real" system.
Sales Invoicing & Dispatch
Sales orders convert to invoices and dispatch from the same record, so the part that leaves the warehouse, the invoice raised for it and the condition it was sold under all stay attached to one another rather than living in three separate places someone has to reconcile by hand.
A Real Double-Entry Accounting Subledger — Not a Bolt-On
Chart of accounts, journals, vendor bills and payments run natively inside the platform as proper double-entry bookkeeping, not as a nightly sync out to a separate accounting package. Every inventory movement, purchase and sale posts straight to the ledger it belongs to, so the warehouse and the books are never two different versions of the truth.
Bulk Excel Import & Role-Based, Audit-Logged Admin
A bulk Excel import tool loads parts, stock and vendor data in batches instead of by hand — built for the initial data load and for any large catalogue update after. An admin console sets who can see and do what by role, and logs every change made, so there's always an answer to who touched a record and when.
The stack
This runs on a plain, boring-on-purpose stack, chosen for the same reason I usually pick Odoo: because it fits the problem, not because it's fashionable. A Node.js and Express API sits in front of a PostgreSQL database — PostgreSQL specifically because the accounting subledger needed real transactional integrity and constraints enforced at the database level, not just in application code. React drives the front end, with separate views for warehouse/procurement staff and for finance, built from the same API rather than as two disconnected tools. In total, it's one custom codebase covering inventory, procurement, repair tracking, sales and accounting — no separate ERP, accounting package or spreadsheet running alongside it.
Why work with me
I'm Muhammad Salman Ali Khan, an Odoo Techno-Functional Consultant in Dubai and Head of Projects at Techbot Information Technology LLC. Most of what I build runs on Odoo — 10+ years, 100+ implementations, certified across Odoo v13, v14, v15, v16, v18 and v19. This project is the other side of that: when a business's workflow doesn't fit any off-the-shelf system cleanly, including Odoo, I design and build the custom platform instead — database, API and front end, end to end — the same way I'd approach an ERP implementation: understand how the business actually runs first, then build to match it.
Related
Two more places to see what "built to fit the business" looks like on both sides of what I do:
Not sure if your operation needs Odoo or something fully custom?
Tell me how your inventory, procurement, repairs or accounting actually work today, and I'll give you a scoped, honest view of the right approach — Odoo, custom software, or a mix of both — at no cost.
Get a free business evaluation