Why ResortPass and What We are Building

I joined ResortPass for what we can become.

People already love our experiences. Partners see real value in the partnership. The mission matters to me. At the same time, many of the decisions that will define our product, technology, and culture are still ahead of us.

That combination is rare. It is why I wanted to be here.

I also wanted to work with people I respect and enjoy spending time with. Hard problems are better when you solve them with good people.

Why We Work

Our mission is to create a world where anyone can live a life in balance.

As a parent, I know how rare a free Saturday can feel. A family can book four hours at a hotel twenty minutes from home and spend the afternoon together by the pool. No plane ticket. No packing. No week away. Just time together that becomes a lasting memory.

That is what ResortPass makes possible.

A guest should be able to find the right experience and book it easily. A partner should be able to welcome that guest without adding operational burden. When we do our work well, the technology disappears.

Effortless Is Hard to Build

A booking may look simple. The system behind it is not.

It must understand what a guest wants, where they are, and what is actually available. It must handle different prices, inventory models, time slots, seats, add-ons, and policies. It must work across payments, currencies, partner operations, property systems, and distribution channels. And it must be reliable across web, mobile, and partner tools.

That complexity is ours to handle.

Make Search and Booking Feel Easy

Finding the right ResortPass experience is not a standard search problem. Relevance changes with location, intent, date, availability, and the kind of day someone wants.

We have started bringing search in-house with OpenSearch. This gives us more control over ranking and creates room for better personalization and recommendations.

Our bar is to create the best consumer experience in our category across web and mobile. A guest should be able to move from an idea to a confirmed booking without friction. Discovery should feel intuitive. Booking should be fast. The whole journey should feel enjoyable.

Model Experiences Well

A cabana may have capacity and add-ons. A massage has a duration and time slots. A day room has its own inventory and cancellation rules. They do not follow the same booking model.

These concepts sit at the center of our product. Getting this right requires deep domain thinking, better data models, and careful migrations. It is foundational work. It will make future product development faster and make it easier to support new kinds of experiences.

Help Partners Make Better Decisions

Partners should not have to piece together how their business is performing.

They should be able to see which experiences are working, how demand is changing, where inventory is going unused, and when pricing needs attention. Our tools should turn marketplace data into practical actions across products, pricing, and inventory.

The goal is not another dashboard. It is better decisions that help partners serve more guests and generate more revenue.

Build One Platform With Many Doors

Guests may find ResortPass on our website, in our mobile apps, through a partner, or on a distribution platform. Partners use property systems, point-of-sale tools, and booking platforms that must work with ours.

The same products, inventory, pricing, and booking rules should behave consistently wherever a transaction starts. That requires dependable integrations, clear APIs, and one coherent platform behind every channel.

The Team Behind the Work

The team already here has created a product that guests love and partners value. Their work gives me confidence in what we can do next.

One recent example is our work to support five additional languages. Engineers joined early, helped shape the requirements and technical approach, and worked with Product to decide what we could deliver well on a tight timeline. We will tell that story in our next post.

We are growing the engineering team in New York. We are looking for builders at heart who care about impact, own outcomes, believe in the mission, and make the people around them better. People you trust, learn from, and genuinely enjoy working with.

How We Want to Work

The best work begins before the PRD is finished. Engineers should join while the problem is still being shaped.

They should understand the customer's needs, question assumptions, work with Product and Design, make the technical tradeoffs, ship the solution, and see what happens in production.

We do this well on some projects. We do not yet do it consistently enough. We are changing that.

Ownership also continues after the code is merged. A feature is done when it works, is tested, is observable, and can be released safely.

Merged is not done. Verified is done.

We want to move with urgency, but speed without quality creates more work. Quality helps us build faster because we spend less time on rollbacks, broken experiments, and fire drills.

We ask engineers to bring ownership, curiosity, judgment, urgency, and high standards. Engineering leadership owes them clear context, meaningful problems, trust, honest feedback, strong teammates, and room to grow.

What This Blog Will Be

This blog will be an honest journal of that work.

We will share the decisions behind our systems. We will write about what worked, what did not, and what we learned. The engineers doing the work will tell many of those stories directly.

I have learned a great deal from open-source software and from engineering teams willing to share their successes and failures. This is one way for us to give back to that community of builders.

There is a lot ahead of us. I am proud of the team doing the work and excited about what we can build together. We will share what we learn here.