Keep Your Dead Ends

"Ever tried. Ever failed. No matter. Try again. Fail again. Fail better." Samuel Beckett, Worstward Ho, 1983

I've been struggling to figure out how to start this for months.

By this, I don't mean this specific post (although that is part of it); I mean the whole shebang:

• writing about things that could add value to other people (instead of just reflecting abstractly)
• building in public in a structured way that invites criticism and engagement
• investing regular, structured time into doing this so that it becomes a habit, not a chore.

The biggest thing holding me back is a standard I set for myself previously. "AI NEVER WRITES FOR ME". It can help me ideate, it can take what I've said and capture key ideas and draft broad outlines, but the actual output is entirely mine.

This sounds honourable, but it is perfectionism disguising fear:

• "it takes time to write properly" so I can always go "no, this client work is more important" and just not write
• if I'm writing in public I can get feedback and (gasp) criticism too
• I feel like an imposter when I look at the achievements of my peers
• what if I start and fail again.

So I'm just starting. My goal is to write as a builder in the process of figuring stuff out, and I welcome your feedback. Critique and all.

The default

Mostly everything you read online in the tech space is about the stuff that worked:

• how this bro earns $50 000 a week from an app he built over the weekend
• how that expert built a system to solve a small personal problem that is now a million-dollar company
• the creative solutions people have found to real challenges
• how-to guides aplenty.

But almost none of the articles I've read detailed what didn't work in any more depth than "it took me a few weeks" or "the first iteration wasn't quite right so I tweaked it and now it's awesome".

It's feel good stuff, but one of the counterintuitive things I've discovered is that failure is more often than not the engine that drives success. In the words of Robert F. Kennedy:

"Only those who dare to fail greatly can ever achieve greatly." University of Cape Town, "Day of Affirmation" address, 6 June 1966

Building systematically

One of my most impactful discoveries while working in Claude has been how important the discipline of structured documentation and filing is. I'll cover that in another post in more detail, but the bottom line is that the better your structure is organised, the smarter Claude feels.

I've started applying this systematic approach to everything I do. Specifically, I've adopted the following three processes.

1. Weekly stand-ups and cooldowns

Those of you working in a context where this is the (sometimes infuriating) norm might roll your eyes at this, and rightly so.

However, as a solo entrepreneur with multiple clients who all have urgent things that need doing, adopting these rhythms has been invaluable for me because:

• they help me shape my week and block time for what is important instead of always being beholden to the things that feel most urgent
• they force me to reflect on what worked during the week, what didn't, and why
• I'm building a historical log that I can use for monthly and quarterly business reviews
• I can see and celebrate progress that would otherwise be invisible.

2. Log the shenanigans

At the end of every conversation with Claude I run a "log the shenanigans" skill, which does the following:

• catalogues everything we covered in the conversation into various file structures (personal development, business stuff, specific projects, writing ideas)
• gives me a short summary of where everything is going (and why if the context requires it)
• commits and pushes to git.

3. Build decision trees

Whenever I reach a meaningful point in a process — whether that's building an app, developing a website, a knowledge project or business development work — I tell Claude to create a decision tree.

For this purpose, a decision tree is a comprehensive record of everything we discussed, all of the branches we followed and discarded and why, and where we are currently.

The purpose is to capture EVERYTHING in as much detail as possible so that I don't have to make the same mistakes twice, or if I do, use those failures to reinforce my systems and learn from the process.

The compounding effect of keeping the branches

One of the main benefits of these processes is that all of my failures and wrong decisions are documented. No dead branches are dropped into the bin, even the really painful ones.

"No dead branches are dropped into the bin, even the really painful ones."

The value of documenting dead branches goes beyond not making the same mistake over and over. Through this process, I'm constantly learning about the judgement calls Claude or I made — or I made based on Claude's guidance — and am able to interrogate the substance of them for first principles, anti-patterns and processes I can apply across multiple contexts.

Save the lessons, archive the work

I was trying to improve the content process for one of my clients, and decided that building a comprehensive register of all of his IP would be really helpful. After hours of building and refining, I shared it with him to resounding indifference because it wasn't directly contributing to the outcome he was aiming for at the time.

In the past I might have quietly written off that work and moved on, but I logged the whole build: what it was, how I'd structured it, why it hadn't fit, then archived it.

Fast forward half a year and that IP register is now the backbone of a project I'm currently working on with him. The work wasn't wasted, and I've been able to apply several of the lessons I learned to other projects that landed wonderfully.

Compound engineering

Kieran Klaassen at the AI tooling, media and software company Every wrote a great piece on compound engineering that helped me shape this process even more. The basic philosophy is that "each unit of engineering work should make subsequent units easier — not harder."

While I'm not working at their scale and my application is different in practice, I have found that the grounding principle of building systems that compound my learning — specifically by logging the whole process and prioritising the failures — has had three significant outcomes for me.

1. Every time I try something new, I'm doing less work to get it to a testable state.

That heading speaks for itself. Less time spent on making decisions I have already made means more energy to focus on building and shipping.

2. I can clearly articulate why I chose certain approaches over others

I often have to make decisions that have meaningful knock-on effects downstream. Whether it's deciding on a tech stack or a strategic approach, having my failure data as well as what worked allows me to make a strong case for what I'm suggesting. Even more importantly, it helps me explain clearly why I'm not confident in a proposed approach, or why options A, B, and C are the wrong fit for this decision.

3. There is fun in my work even on the days that just SUCK

I learned long ago that I work best when I'm having fun and enjoying what I'm doing, and creating things that solve problems that matter and work as they are intended is a huge delight.

So even on the back of an exhausting day where nothing went right, I'm aware that I'll be able to mine useful insights from my reflections and failures, and taking 15 minutes to vent to Claude isn't just therapeutic, it is a critical business function that is literally going to help me pay my bills.

Things to steal from this post

This was a lot, so here's an overview. I'd love to hear your thoughts on this, whether you do anything similar and how it works for you.

1. Run weekly stand-ups and cool-downs. Shape your week around what's important instead of what feels most urgent, and build a historical log for your monthly and quarterly reviews.
2. Log the shenanigans. At the end of every conversation you have with your LLM, catalogue what you covered, summarise where it's going, and commit it, so you're never rebuilding context from scratch.
3. Build decision trees. Record every branch you followed and discarded, and why, so you don't make the same mistake twice, and your failures reinforce your systems.
4. Keep the dead ends. Don't drop your wrong decisions in the bin, even the painful ones. The judgement calls are where the first-principle learnings live.
5. Mine the bad days. Even when nothing goes right, fifteen minutes venting to your LLM can turn an exhausting day into useful insight that's both therapeutic and a critical business function.

Until next time, with love, good spirits and better music 🕺

David