Massage Service Hub
www.massageservicehub.com
An Ezion-owned product connecting massage business discovery and booking with the operational tools used to run the service.
Visit siteDevelopment & operation notes
Two audiences, one source of truth
A visitor browses Sydney shops and therapists by suburb and by service type, opens a shop profile, and compares services, prices, therapists and booking options. A participating business edits the same records from its own administration surface. Because both sides read the same data, a change made by the business is the change a customer sees, and the platform does not need a reconciliation step between a public listing and an operational one.
Discovery that stays honest
Shops are browsable by suburb, by service category and on a map, and profiles carry a completeness indicator so a partially filled listing is visible as such rather than presented as finished. Featured placements are labelled as paid priority listings wherever they appear, so a visitor can tell promotion from ranking. Those are product decisions, not styling: they determine what the directory is allowed to imply.
Built to keep running while it changes
The public site, the business administration interface and the shared backend are deployed as separate services behind a single reverse proxy, with health checks in the release path and centralised logs. The product is continuing work rather than a finished portfolio piece, so each change is judged against a system that has to stay usable while it is modified.
The problem the product addresses
Massage Service Hub brings public business discovery and booking together with the tools a participating business uses to manage its service. The public experience and the operating experience are treated as one system: availability, business information and booking decisions need to remain consistent across both.
What Ezion is responsible for
Ezion designs, develops and operates the product. That includes the public directory and booking journeys, business administration interfaces, shared backend services, deployment automation and operational monitoring. The product is continuing work rather than a finished portfolio mock-up, so decisions are tested against a system that must remain usable while it changes.
What this demonstrates
The work demonstrates product planning across customer and operator needs, responsive web delivery, API and data integration, release discipline and day-to-day operational ownership. We describe the system itself rather than publishing unsupported customer outcomes. Public product pages are linked so visitors can inspect the live service directly.