Two weeks building MooTrip: a retro on what I built

MooTrip is an AI trip planner. I built a first version in three days, replaced it on the fourth, and spent the rest of two weeks making the new one dependable. This is a retro on the decisions: what went well, what did not, and what I will do differently.

The short version: changing direction early was the best call I made, and I should have tested the idea before building the version I threw away.

What happened

• Days 1 to 3: a conventional planner. You swiped through places and code arranged them into days, with hotels, a map and share links.
• Day 4: I replaced it. A language model now writes the whole itinerary and you change it by chatting.
• Days 5 to 13: checks, retries and fixes so the model's plans could be trusted, and polish.

What went well

I changed direction early. The first version worked, and I replaced it anyway. The rewrite took one day. Waiting a month would have made that decision much harder.

I started on reliability the same day. About four hours after the rewrite went in, so did the first safeguard: a plan that fails a check is sent back to be corrected, and an answer that runs on too long is stopped.

I checked the model and the map against each other. When the two disagree by a wide margin, the app now treats that as an error to resolve. The story behind that is below, under surprises.

I acted fast on cost. When a paid maps API was running up charges, I switched the app off, removed the API and had it back on in 61 minutes.

What did not go well

I built a full product before testing the idea. The first version had hotels ranked by travel time, a map, sharing and sign-in. The swipe deck and the code that arranged the days were removed on day four. A one-day prototype of the chat approach would have told me the same thing.

I found out about API costs the hard way. Switching the app off was the right fix, but it should never have been needed.

I went back and forth on what the model should do. I had code fill in the nights and flights, then two days later handed them back to the model. The same happened with fixing overlapping times.

I worked out who it was for on day 11. The positioning and audience research came after most of the product was built.

What surprised me

The model was right and the map was wrong. One trip warned of a 49-hour drive. The model had estimated 20 to 30 minutes for each leg. The map lookup had placed one stop 2,400 km away. I had assumed the external service was the reliable one and the model was the thing to check.

The rewrite was the quick part. Getting a model to write a full itinerary took one day. Making those itineraries dependable took the nine days after, and the first safeguard was needed within hours.

What I will do differently

• Prototype the riskiest idea first, in a day, before building anything around it.
• Set a spending limit and an alert before using any paid API.
• Cross-check from the start. When two sources give the same figure, compare them and flag large gaps.
• Decide the split once. Write down what the model owns and what code owns before building, and change it only with evidence.
• Do the audience work in week one.

The number I will watch: how often a change to a plan passes every check on the first attempt. On my test set it was 33 of 40 at last count, and 39 of 40 after one retry. I want the first number higher.

If you are about to hand a task like this to a model, plan for the rewrite to be the short part. Making the output dependable took most of my two weeks.