I sent Artemis, my AI assistant, a movie trailer and asked for help planning a night out in South Florida.
I wanted to find the movie in the right format, build an evening around it, and include an activity I’d been wanting to try. Pretty normal request. I wasn’t asking for an app. I definitely wasn’t sitting down to design a new service for The Green Anchor.
Then I kept making the request more like my actual life.
Maybe it would be a night with a friend instead. Maybe a family outing. Dinner should fit. There could be a couple of optional stops afterward. One person could only join on Saturdays. And eventually, I wanted the opening activity to be a surprise.
By the time I saw the Saturday mystery dashboard, I was genuinely excited about what this had become.
The outing is still ahead of us. This is the story of building the plan, not a review of a night that already happened.
A list of places still leaves you doing the planning
Finding somewhere to go is usually only the beginning.
You still have to work out whether the times fit, whether everyone can attend, how much the group is committing to, and which details need checking before anyone pays. A restaurant can be open without having a table. A movie can be listed without having enough seats together. A theater advertising a premium format doesn’t prove that your particular screening uses it.
I wanted something I could open on the night and follow.
The research became a mobile page with a sequence, arrival targets, routes, booking links, cost notes and optional stops. I asked for my current website design, and the guide took on The Green Anchor’s typography, colors and light/dark themes.
It started to feel like something made for us rather than a travel article I had to translate into a plan.
I wanted a surprise, so the guests needed a different page
Then I asked for a mystery version.
The organizer still needed the actual activity, location and operational details. The guests needed enough information to show up, dress appropriately and enjoy the reveal.
That became a separate dashboard with a different photo, a classified first mission, a few playful hints and a preparation checklist.
I particularly liked that the answer wasn’t just hidden behind a button. The guest version left it out of the page, its links, and the saved and printed copies. The full organizer version stayed separate.
That’s a small design choice with a lot of uses. A surprise birthday, an anniversary, a group outing or an event can all need different versions of the same plan.
Moving it to Saturday changed more than the date
One of the best parts of the process happened when a friend’s availability forced a change.
It would have been easy to copy the itinerary and replace the date at the top. That would have been wrong.
The original afternoon activity time didn’t have enough places left for the group on Saturday. An earlier session did. The movie times were different too.
The new version put the activity first, the movie next, and dinner afterward. It also moved the optional stops and changed the route so it started from dinner instead of the cinema.
Those are the little details I’d otherwise be checking across a pile of tabs. Getting them onto one page made the plan easier to judge, including the tight transition that still needed confirming before booking.
Nothing was purchased automatically. Available when checked, listed, and booked remained different things.
The group totals made me think about travel
The feature I keep coming back to is the budget control.
I could change the group size and see the known costs update. Four people. Five. Six. I didn’t have to redo the same calculation or wonder which number in the chat was still relevant.
In this prototype, the checked activity price was $39.99 per person. The optional three-course dinner was $39.95. Those two items came to $79.94 each:
- Four people: $319.76.
- Five people: $399.70.
- Six people: $479.64.
Those were planning figures from the research snapshot, not a current quote or the price of the whole night. Movie tickets, taxes, tips, fees, transport and optional extras were separate.
Keeping that boundary visible matters. A neat total is worse than useless if people assume it includes things it doesn’t.
The current version calculates those known subtotals for the selected headcount. It doesn’t yet allocate different activities to different people or track who owes whom. That next layer is where I see a lot of potential.
A fair split depends on who is doing what
Group trips get complicated long before anyone owes money.
One person skips an excursion. Someone joins a day late. A couple shares a room. A rental has a fixed cost, while admission is charged per person. Only part of the group wants the expensive dinner.
Dividing the entire trip by the number of people doesn’t describe any of that very well.
I’d like the next version to show each activity, who’s joining it, how that cost is shared, and what each person is agreeing to before booking. Someone could opt out of an activity and see their own planned total change without changing everyone else’s plans by accident.
Then there’s a separate question: who paid already, and who needs to reimburse them?
I’d keep that distinct from the planning estimate. Estimated cost, agreed share, actual charge and payment received shouldn’t all appear as the same number. Deposits, refunds and cancellations make that distinction even more important.
That’s the part I think could be gold for travel planning. People could understand their share while they’re deciding what to do, instead of trying to reconstruct the agreement afterward.
It’s an idea to build next, not a payment feature I’m claiming already works.
There’s a service idea here, but I’m keeping it grounded
I now have working private guides, an anonymous service concept, a playbook and a project to develop it further.
The guides have interactive budgets, optional routes, printable copies and a guest version that preserves the surprise. The idea has a working name: Night Out by The Green Anchor.
I can see a small service where someone gives me their interests, area, group size and budget, and gets a researched evening they can follow. A sensible first version would stay narrow, with customers booking and paying venues directly.
That would let me learn how much people value the planning, how much work each guide takes, and which features are worth improving. Liking my own prototype doesn’t answer those questions.
I’m also interested in whether the same format could help a local host or venue give guests a useful guide. That would be a different offer with different maintenance needs.
Where I’d like to take it
API access could make parts of the research easier to refresh: places, routes, events and, where a provider permits it, travel or reservation information. I’d still need to check access rights, costs and what the data actually proves. A listing feed isn’t necessarily live inventory, and live inventory isn’t a reservation.
Travel planning would add more than extra days. It would mean handling transfers, time zones, different arrival dates and changing costs. Coordination would add another responsibility again: making a booking, sending a message, changing a reservation or accepting a cancellation fee.
I want those actions to require a clear approval, rather than treating a planning request as permission to spend money.
For now, I’m preserving the parts that made this useful and deciding what to test next. Participant-specific cost splits are high on that list.
I started by trying to put together a good night with people I care about. Building the plan showed me a problem I’d enjoy solving for other people too.