Designing and building a group holiday decision app with AI

For the last 18 years, my wife Kelly has organised our extended-family holidays.

With four adults and four children to consider, we need to agree where to go while working around a maximum budget. Kelly researches holiday providers, travel websites and Tripadvisor reviews, writes down huge amounts of options she thinks could work, then sporadically shares links through WhatsApp and email.

The links get lost. My sister-in-law doesn't really use email. My sister-in-law and I are rubbish at contributing and, when we do, it's usually the wrong dates. We lose interest quickly.

Kelly is effectively the Holiboss.

I thought there had to be a simpler way: give one person somewhere to bring all those options together, then make it ridiculously easy for everyone else to take part in the decision.

I was going to build it anyway, but putting my real-life product hat on, if there was any chance of Holiboss becoming commercially useful, I needed to understand whether other people had the same problem.

I spoke to people directly and used social channels including Instagram and LinkedIn to gather feedback. I also used AI to research wider online conversations and behaviours, including communities such as Reddit.

The core problem wasn't finding holidays. Kelly was already extremely good at that.

The problem was getting everyone else to look at the options and work out which holiday the group actually liked most.

Holiboss was designed around that decision.

One person creates the holiday and adds all the options they’ve found. Everyone else sees the same shortlist, votes Love, Like or Nope and can discuss each option in its own chat. Holiboss brings all that voting together and works out the group favourite.

I designed different levels of participation around the reality I'd seen in my own family. The person doing the work needs control, while everyone else should be able to contribute with almost no effort.

Discovery surfaced plenty of ideas for where Holiboss could go next.

One that came up was dates: could Holiboss also help a group work out when everyone could actually go?

It made complete sense, but it wasn't the problem I wanted the first release to solve.

The core problem was: given a group of holiday options, which one does everyone like most?

So V1 stayed deliberately focused on the where. Add the options, bring everyone into one place, vote, chat and reach a group favourite.

Date coordination went into the backlog for a later release, along with other ideas I kept track of in Trello.

That was a deliberate product decision. I wanted to prove the core behaviour with something people could actually use rather than keep expanding the scope before I'd shipped anything.

Part of the reason for creating Holiboss was to experiment with how far the new generation of AI tools could take me.

I didn't want to use Figma in the traditional way, designing a complete product and then handing it over for development. Plus, I had no one to hand it over to. I genuinely didn't know what the process was going to be.

I initially used V0.dev to move quickly from ideas into working interfaces. That speed was useful, but it also made it easy to jump ahead. Screens were taking shape before some of the end-to-end journeys and edge cases were properly resolved.

I stopped building, went back into Miro and mapped the journey properly before continuing.

I started Holiboss as a web app because, at the time, building and shipping a proper mobile app without development experience didn't feel realistically achievable.

But the capability of the tools changed quickly.

What had looked difficult at the start of the year became possible enough that I decided to build the mobile product too.

Using React Native, Expo, Supabase and AI-assisted development, I took Holiboss from a website to a mobile app running across iOS and Android.

The first mobile release took around four weeks.

That included far more than designing screens. I had to learn and manage the realities of shipping software: authentication, data, builds, environments, TestFlight, App Store submission, Google Play, releases and production issues.

It was a very different design exercise from producing a prototype.

Once people started using Holiboss and I continued gathering feedback, dates kept coming back.

People didn't just need help deciding where to go. Groups also had the familiar problem of working out when everyone could actually go.

It was a problem I'd already heard during the original discovery, but deliberately left out of the first release.

Now there was a reason to bring it back.

Rather than simply adding a shared calendar, I designed Date Check around the decision itself.

The organiser defines the possible holiday window and length. Everyone shares when they're available or unavailable. Holiboss then works out the strongest dates for the whole group and presents the best options back for review.

Availability gets complicated very quickly.

People might be completely flexible, have specific dates they can't do, prefer certain dates or be able to take holidays of different lengths. Some people respond immediately. Others don't.

The product needed to absorb that complexity rather than expose it.

I designed the flow around simple questions such as “What dates can't you do?”, with people able to type or speak their availability naturally.

Behind that simple interaction, Holiboss compares everyone's availability and ranks possible departures based on group compatibility, preferences, flexibility and holiday length.

The result isn't another calendar to interpret.

It's a recommendation:

Depart between 7–21 Sep · 7 nights

Everyone can make a 7-night holiday starting in this window.

The organiser chooses a date window, decides whether the group should also agree the holiday length, then sends Date Check to everyone.

Group members can quickly share when they can go, using natural language to describe dates they can't make, then choose the holiday lengths that work for them.

As responses come in, Holiboss compares everyone's availability and works out the strongest dates for the group.

I wanted Holiboss to feel distinctive rather than like another generic travel utility.

I vibed out the name with ChatGPT. I wanted something quirky and memorable, and I was always conscious of finding something that could almost be used as a verb: the person taking charge of the holiday is the Holiboss.

I also wanted the .com, so I checked domain availability as I explored names rather than treating it as something to solve afterwards.

The same thinking extended into the social content. I started with ‘Decide faster’, directly reflecting the product proposition, then evolved it into a broader brand idea around getting to the good part of a holiday faster.

I set up TikTok and Instagram accounts and built up a bank of travel content from my own holidays and friends' Instagram photography, asking them if I could use their images.

Building the product was only part of the job. I was also learning first-hand how difficult distribution is when you don't already have an audience.

Holiboss became an experiment in a question I was increasingly interested in professionally:

What happens to product design when one person can move from idea to production software without a traditional delivery team?

The answer wasn't that product design became less important.

What jumped out at me was that:

Holiboss is now a working product across web, iOS and Android, built around a real problem I experienced first-hand and then validated with other people.

I took it from research and proposition through product strategy, brand, UX, technical implementation, app-store releases and ongoing iteration.

Much of it was built during early mornings and weekends alongside my consulting work.

The biggest challenge now isn't whether I can build the product.