Two weeks building MooTrip: a retro on how I worked

I built MooTrip, an AI trip planner, in two weeks on my own. Afterwards I went through the git history the way a team would run a sprint retro: what went well in how I worked, what did not, and what I will change.

The short version: I shipped every day and kept each piece of work small, but I settled designs by trial and error and measured myself by the wrong number.

The sprint in numbers

• 13 days, 27 September to 9 October
• 187 commits, with at least four on every day
• Most days: about 5,000 to 7,000 lines changed

What went well

I shipped every day. No day passed without finished work going in. Measured by lines changed, the pace was steady: eight of the thirteen days landed in the same range.

I kept each piece of work small and finished. For the first eleven days, 130 of 145 commits were complete pull requests, each one a feature or fix that worked when it was merged. Nothing sat half done for days.

I changed the size of my steps to suit the work. When I changed how plans are stored and checked, the prompt, the checks and the test samples had to change together, so those went in as a few large changes. When I was adjusting how the landing page looked, I saved after every tweak.

Visual feedback was fast. In one hour I made 29 small changes to the landing page and chat box, looking at the result after each. A menu went through five shapes in 16 minutes.

What did not go well

I designed by trial and error. That menu ended up as a plain rectangle, the simplest of the five shapes. A glow at the top of the page changed height four times in six minutes. Fast feedback is useful, but I was using it in place of deciding what I wanted first.

I read commit count as progress. My busiest day by commits (33) changed some of the least code. My quietest full day (5 commits) changed almost four times as much. The count mostly reflected whether I was doing visual tweaks or structural work, and it told me little about output.

The history got noisy at the end. On the last two days I merged dozens of tiny commits as they were. Anyone reading the history now has to wade through "glow a bit longer" to find what changed.

Some days ran past midnight. Three days have commits after midnight. That is not a pace I could hold for longer than two weeks.

What surprised me

The pace was steadier than it looked. By commits, my days ranged from 4 to 33. By lines changed, most of them were about the same size. The swings in the commit graph were mostly swings in the kind of work.

The simplest design won. I tried four more elaborate menu shapes before settling on the plain rectangle.

What I will change

• Sketch before tweaking. Decide between two or three options on paper, then build one. Give visual polish a time limit.
• Stop counting commits. If I want a rough measure of a day, I will look at what shipped.
• Tidy before merging. Keep the tiny commits while I work, and combine them into one before they go into the main history.
• Set a stopping time.

The number I will watch: how many attempts a visual change takes before it settles. This sprint it was five for the menu and four for the glow. Next time I want it at two.

If you want to run the same retro on your own project, look at commits per day next to the size of each commit. The gap between the two is where I learned the most.