Choong Teik Tan

Software Engineer

Layer 04 / Case Study Detail

Travel experiences platform

Case study live

Travel Experiences Widget Platform

A truthful architecture case study covering the travel experiences widget platform operating model, stack footprint, and delivery posture reflected in the current Qantas Hotels experience baseline.

Executive summary

Travel Experiences Widget Platform

active

This case study documents the public, supportable view of the travel experiences widget platform work represented in the Qantas Hotels experience baseline.

The platform scope spans stakeholder advisory, platform design and delivery, and a broad technical stack across front-end, back-end, DevOps, and operational tooling.

Category
Platform
Sections
9
Source note
Grounded in the audited Qantas Hotels experience route content and current typed experience data. No private business metrics or internal-only architecture claims are included.

Publishing status

Public baseline

Current documented state

This case study is intentionally limited to public, approved facts. It documents the current supportable architecture and delivery story without exposing private platform details.

Return to the projects index or use the experience route for current validated delivery history.

Section 01

Problem statement

The documented role required engineering support for travel-experience surfaces while staying close to business needs, technical advisory, and end-to-end delivery responsibility.

In practice, that meant the platform had to serve real stakeholder objectives without splitting architecture, implementation, testing, and operational ownership into isolated tracks.

Section 02

Constraints

The public source material shows a platform under active business pressure: workload prioritisation, critical-objective focus, and broad delivery scope were all explicit parts of the role.

  • Business priorities could shift, so work had to stay aligned to critical objectives.
  • The operating footprint spanned front-end, back-end, DevOps, and observability rather than a single narrow team boundary.
  • This public case study must remain truthful and cannot disclose private product metrics or internal diagrams.

Section 03

Architecture

The documented platform footprint spans a React-based front end, service and API work across Ruby on Rails, NodeJS, and GraphQL, plus a delivery and operations layer using Buildkite, Terraform, Docker, Kong API Gateway, AWS services, Datadog, Splunk, and New Relic.

The same experience record also shows supporting architectural patterns and analytical tooling such as CQRS, Event Sourcing, and Google Analytics.

  • Front-end surface: ReactJS, Redux-Saga, Redux-Logic, Styled-Components, Styled-System, Storybook for React, React Cosmos, Cypress E2E Testing
  • Back-end and API layer: Ruby on Rails, NodeJS, GraphQL
  • Platform and delivery layer: Buildkite, Terraform, Docker, Kong API Gateway, AWS services, Datadog, Splunk, New Relic

Section 04

Key decisions

The clearest supportable decisions in the public record are organisational and architectural rather than metric-driven. The role explicitly combined stakeholder engagement, technical advisory, scope-to-test ownership, and IT COE advocacy.

  • Keep stakeholder discovery close to engineering delivery instead of treating architecture as a separate after-the-fact review layer.
  • Promote an IT COE model with business stakeholders so technical governance stays visible during planning and delivery.
  • Carry expertise across scope, design, development, implementation, and testing rather than optimising one layer at the expense of the whole platform.

Section 05

Trade-offs

A broad platform scope creates stronger system understanding, but it also means engineers must balance business context, implementation depth, operational readiness, and delivery prioritisation at the same time.

  • Wide stack ownership improves architectural continuity, but raises coordination and context-switching load.
  • Observability and operational tooling increase control over production behavior, but add delivery surface area that also needs to be maintained.
  • Keeping this case study public and truthful means some internal platform specifics remain intentionally undisclosed.

Section 06

Delivery approach

The audited responsibilities show a delivery model built around stakeholder engagement, technical advisory, end-to-end implementation support, and workload prioritisation against critical business objectives.

The same record also reflects self-development and mentoring as part of the delivery posture, which matters when a platform needs to scale through people as well as code.

  • Engage with stakeholders to understand business needs and provide technical advisory services.
  • Advocate and promote IT COE model with business stakeholders.
  • Provide expertise across scope, design, development, implementation, and testing.
  • Prioritise workload to focus on critical business objectives.
  • Develop deeper technical proficiency in critical technologies.
  • Drive self-development and mentor others for continuous improvement.

Section 07

Results and current state

The supportable public result is an ongoing platform role that has remained active since July 2018, with visible depth across front-end, back-end, DevOps, and architecture-adjacent practices.

This case study intentionally records the platform footprint and delivery posture rather than claiming private conversion, revenue, or performance metrics that are not approved for publication.

  • Current public role baseline: Software Engineer, July 2018 - Present.
  • Platform architecture, implementation, testing, and operations all remained part of the documented engineering scope.
  • The public MAXMUS record can now point to a concrete case study without inventing outcomes.

Section 08

Lessons learned

Travel-platform work benefits from keeping architecture close to business priorities rather than treating stakeholder understanding and technical execution as separate concerns.

Wide platform ownership also reinforces how important delivery discipline, observability, and clear prioritisation become when the same team touches experience, APIs, and operational tooling.

Section 09

Future evolution

If publication scope expands later, this case study should be extended with approved widget-level details, deeper system boundaries, and more explicit implementation narratives for the platform architecture.

  • Add approved component-boundary or integration detail only when it can be published safely.
  • Expand the case study with architecture diagrams or rollout sequencing only if those artifacts are cleared for public release.
  • Keep the current version as the truthful baseline rather than filling gaps with guessed outcomes.