A resort group rebuilt its website and guest app with two partners. We run product ownership on the group's side, so brief, decisions and scope stay in one place.
Engagement scope as of October 2026. Delivery metrics will be added after go-live.
Website, guest app and back-end systems, built by two partners for departments with their own priorities. Someone on the client's side had to make it one product.
The app is designed by one partner and built by another. Every handoff is a place where a feature can fall between contracts and go unpriced.
Requirements were written before the platform limits were clear, so some items had to be rewritten before a partner could price them.
Each department had a strong case of its own, and not all of them pointed the same way.
The booking engine and other third-party systems each limit what the new front end can promise guests.
We reviewed the brief before partners priced it, built one evidence base, and took each constraint to the people who could decide on it.
Sequence only. Dates are kept out of this case study.
OutcomeScope questions answered before signature, not in change requests.
OutcomeBoth partners design from the same findings.
OutcomeEach change request traceable to its source.
OutcomePlatform direction agreed before build scoping.
OutcomePartners work from the same, settled scope.
OutcomeLess dependence on any one partner after launch.
OutcomeScope questions answered before signature, not in change requests.
OutcomeBoth partners design from the same findings.
OutcomeEach change request traceable to its source.
OutcomePlatform direction agreed before build scoping.
OutcomePartners work from the same, settled scope.
OutcomeLess dependence on any one partner after launch.
Requests come from departments, hotel teams, leadership and both partners. Each passes through the same product layer before it reaches a partner.
One route for every request. Nothing reaches a partner without a classification and a source.
Four brands, different guests, one portfolio. Decisions are settled once where the brands share and kept apart where they differ.
Hosting, security, analytics and CMS choices are made at group level, so each brand doesn't repeat the same evaluation.
Shared components and standards sit underneath; tone, content and guest experience stay with the brand.
What one brand's project teaches about partners, platforms and content goes into the next brief.
Maintenance and support needs are estimated from what the existing sites actually required, not from a generic retainer.
| Area | Before | Now |
|---|---|---|
| Feedback | Each department talked to partners directly | One register, classified and sourced |
| Constraints | Found during design | Taken to decision makers first |
| Decisions | Made in meetings, remembered differently | Logged with an owner and the reasoning |
| Scope changes | Handled case by case | Logged, priced or held for later |
| Content after launch | A ticket to the partner | In-house, AI-assistedplanned |
Now: One register, classified and sourced
Before: Each department talked to partners directly
Now: Taken to decision makers first
Before: Found during design
Now: Logged with an owner and the reasoning
Before: Made in meetings, remembered differently
Now: Logged, priced or held for later
Before: Handled case by case
Now: In-house, AI-assistedplanned
Before: A ticket to the partner
Neither partner was the problem. The features nobody owned were. Mapping every handoff early showed where scope would otherwise have gone unpriced.
When a feature guests want depends on what a third-party platform allows, the answer isn't a cleverer design. It's a decision for the people who own that platform and its commercial terms, so that's where we take it.
Summaries drift. A note that said one thing could be paraphrased into a stronger claim. We use AI to consolidate at scale and anchor every critical item to the stakeholder's own words.
Tell us what you're building and who's building it. We'll show you where the gaps are likely to be and how we'd run the product side.
