Delivering an Equipment-Booking Module to Onboard Saudi Aramco
Problem
Saudi Aramco needed an internal equipment-reservation system: departments reserve equipment, use it, and return it by a deadline so the next department can book it. It had to be delivered on a hard timeline as the condition for onboarding them onto the platform.
Constraints
- Fixed delivery window — roughly two and a half months, targeted for two
- Built essentially from scratch: data model, backend, and UI
- A 7-engineer team to coordinate across engineering and QA
Architecture
We remodeled an existing procurement flow into a purpose-built booking domain: new data model and collections, backend services, and a UI built from the ground up. I owned the module end-to-end — coordinating the team, tracking scope across engineering and QA, and verifying completion against the deadline. Bookings move equipment through a reserve → in-use → return lifecycle so availability is always accurate for the next department.
Trade-offs
Why: The booking lifecycle and data model were different enough that forcing it onto procurement would have cost more than a clean build.
Cost: More upfront work under a tight deadline.
Why: One person holding the end-to-end picture kept scope and QA aligned under time pressure.
Cost: Required constant communication across engineering and QA.
Outcome
- Delivered within the deadline and onboarded Saudi Aramco onto the platform
- Aramco manages ~200 pieces of equipment through the module
- A reusable booking domain the platform can extend to other customers