Hotel PMS with Gym and Restaurant
One guest folio across three businesses on one site, so a hotel guest using the gym and the restaurant is a single account.
Problem
A hotel also operating a gym and a restaurant had three systems and therefore triple data entry, with no unified view of a guest who used all three. Cross-subsidiary charging is the specific thing that breaks: a guest signs for lunch and the charge needs to reach their room folio.
Approach
Twenty-one interlinked models across the three subsystems sharing one guest identity, so hotel stays, gym membership and restaurant billing all resolve to the same person and the same folio. An admin frontend served directly from the API, plus a technical README with diagrams, because a system this interlinked is unmaintainable without one.
Outcome
One guest record follows the customer across all three businesses, and management sees consolidated revenue instead of three partial pictures.
How it's built
Shared guest identity across three subsystems, with charges from any of them able to post to a single folio.
One guest identity across all three businesses
The cross-subsidiary charge is the reason the client wanted one system. Separate identities per subsystem means matching people by name, which fails on the first duplicate.
The guest model has to satisfy three different sets of requirements, making it the most constrained entity in the schema.
Adjacent systems
Bookstore E-commerce over an Existing ERP
A storefront, admin dashboard and API sitting in front of the client existing ERP, which stays the source of truth.
E-commerce and ERP Backend
GraphQL commerce backend where the client rearranges their own storefront from the dashboard, over an inventory ledger with a single mutation point.
Hardware Retail Platform with ERP Sync
Storefront, app and operations dashboard sitting in front of an external ERP, with data flowing both directions and staying consistent.