Start with one

When I moved to London, I had one rule: this city is only bearable if you don’t take the tube. So I cycled everywhere, and with each new discovery - a hidden cafe, a friend’s flat in an unexplored neighbourhood - I’d drop a star on Google Maps.

Google had just rolled out this feature, and I was both grateful and frustrated. Just one star? No categories? How was I supposed to organise my city? Wouldn’t it be perfect to have separate lists for cafes, restaurants, “maybe later” spots? This could be so organised! Instead, I was stuck with simple, identical stars scattered across my digital map.

But I kept saving. Almost every day, a new star would appear. Without categories to overthink, without descriptions to craft, I just marked and moved on. The friction was so low that saving became automatic - see something interesting, drop a star, keep cycling.

Years later, I opened my map of London. There it was - my entire journey through the city, fossilised in simple stars. The map had become a time capsule. Cafes marked “permanently closed” in red cursive, like tiny digital gravestones. Addresses that no longer made sense. But every star still held a memory, unmarked by category, pure in its simplicity.

And then I noticed: Google had finally added what I’d wanted. Along with stars, there were now options for “Want to go,” “Favourites,” custom lists. Everything I’d wished for was there.

But now, with every save, I faced a decision. Which list? What description? Should this cafe go in “Favourites” or create a new “London Cafes” list? The very feature I’d craved had become a speed bump. In getting what I wanted, I’d lost what I needed: the simple satisfaction of just marking a moment.

That map of London became one of my guiding principles, not just for design but for life: Start with one.

One category is simple to add - it removes doubt. One is already whole - where multiple subcategories will never quite cover everything. One is perfect to start and see structure evolve - you can always split things out later, with better knowledge. One means less coordination between parts.

I see this principle everywhere now:

• Start with one module or namespace in your code. Your structure will emerge from actual use, not imagined architecture. Those empty modules you create based on how you think your programme will evolve? They’ll almost certainly be wrong.

• Starting a new project? Wondering if you need separate repos for infrastructure, docs, and the app itself? Start with one repo. You’ll move faster when all the context is together. You can always split it out later - but you probably won’t need to.

• Even in life: instead of creating elaborate systems for organising photos, notes, or goals, start with one simple method. Let complexity emerge from necessity, not anxiety.

So here I am, restarting my blog with just one post. No categories. No tags. No grand content architecture. Just a simple star on the map of what’s to come.

Because sometimes the best way to build something complex is to begin with something beautifully, frustratingly simple. The structure you need will emerge from the journey itself - and it will fit better than anything you could have planned.

After all, my perfectly uncategorised stars told the story of my London better than any taxonomy ever could.