Articles

Why Time Units Beat Story Points Every Time

Story points, t-shirt sizes, and fibonacci numbers. We have created an entire vocabulary to avoid saying what we actually mean. The truth is simpler: we should just use time units.

This realisation emerged from years of watching teams struggle with abstract estimation systems. The solution was right in front of us all along.

Startup Success Stories Are Flawed

In his book on mapping business strategy, Simon Wardley makes an observation that struck me hard recently.

You cannot learn chess from a list of moves. Even with access to every grandmaster game ever played, simply studying the sequence of moves will not make you a strong player. Without understanding the board position, the strategic context, and the invisible forces at play, these move lists are merely shadows of the actual game.

This observation triggered a thought that has been bothering me about how we approach startup knowledge and learning.

How To Get Clarity With a New Tech Team

You have just taken over a new tech team. There is pressure to deliver, not much signal, and everything feels urgent. Perhaps the roadmap is packed. Perhaps the team seems busy. But is anything really working?

This is your field manual. If you are overwhelmed and trying to get clarity, start here.

Coding with AI: How To Do It Well And What This Means

I am shipping AI-first production code every day. Not experimental features. Not throwaway prototypes. Real, deployed, mission-critical code powering Cherrypick’s tens of thousands of users.

Social media overflows with “vibe coding” demonstrations. These flashy but superficial examples show AI apparently conjuring perfect code in seconds. The reality of professional AI-assisted development runs much deeper. Real production work with AI is messier, more nuanced, and demands rigorous thinking, but very effective.

This is not about magical code generation. It is about a new way of thinking about development. It requires substantial real-world development experience to do well: the onus is upon those of us with this experience to teach the next generation how to harness these tools effectively.

This is how I am doing it, what it all might mean, and how we can help others find the way.

How To Avoid Bad Startup Culture

If you are not paying attention to your startup culture, I have news for you: you are already building a culture into your company. Chances are that is not the culture you want.

Every company has a culture. It is a summation of all the habits and practices that make up the work. It is every choice, good or bad, made by every person involved. Every action sets a precedent, a “how we do things here.”

This is how we are wired. We are naturally social beings and are strongly predisposed to fit in to the group we find ourselves in, and to emulate their behaviour. This reinforces culture further, and compounds when more people are involved.

A culture grows like plants in a garden. You cannot stop the life from growing, but you can decide how and where it grows. Left unattended, weeds will grow alongside the flowers. The key is recognising this and putting in the work to shape it.

Here is a quick primer on how to do the minimum to avoid bad culture, and how to get good culture going with a little attention every so often.

Prompting Sucks (And What We Can Do About It)

Prompting sucks. If you have spent any time working with LLMs, you already know this.

It is not just that prompting is difficult - it is fundamentally broken as an approach to working with AI. It is brittle, model-specific, and endlessly repetitive.

Here is why we need to move beyond prompting, and what we can do about it.

Founder mode is emergency surgery

“Founder mode” is emergency surgery. It is not the right way to run a healthy business.

If your company is sick, you need to fix it. That means courageous decisions only you can make. You will need to dive in and operate sometimes. That doesn’t mean you create bottlenecks by deciding everything for years to come.

How to Build a Robust LLM Application

Last month at Cherrypick we launched a brand new meal generator that uses LLMs to create personalized meal plans.

It has been a great success and we are pleased with the results. Customers are changing their plans 30% less and using their plans in their baskets 14% more.

However, getting to this point was not straightforward, and we learned many things that can go wrong when building these types of systems.

Here is what we learned about building an LLM-based product that actually works, and ends up in production rather than languishing in an investor deck as a cool tech demo.

Why Hybrid Work Works

As someone who lives an hour and a half from my London office, I love working from home. I can help my teenagers out of the door in the morning, and I am present when the family comes home. I can have coffee with my wife Ellie before we start work. I prepare dinner during my lunch break, and receive deliveries. I can contribute more effort during my day to Cherrypick, free from distractions, interruptions and the long commute. I would struggle to work effectively five days a week in London.

I also love working from the office. It is an opportunity to spend real time with the people I work with. Communication is easier and I spend less time on screens. I can train less experienced colleagues much more efficiently than video chat. I can ask for and give advice and help in person, cutting down long feedback cycles. I would struggle to work effectively five days a week from home.

Much of the debate around hybrid working appears to be a zero sum argument about why working from home is “better” or “worse”, and why working in the office is “more” or “less” productive.

One is not better than the other; they are just different. I think we need both for a balanced life.

Here are some pointers for how to have a productive conversation about hybrid in your team.

The Job Is Not To Build

Startup CTOs or founding developers are the first technical people in the business. It is natural to think your job is to write code and build software. This is backwards.

Your first job is not to build software. Your role is to use your technical expertise to help the startup figure out fast if you have a valid solution to a compelling problem, and then a valid product for a big enough market.

You might do this through building software, but you might not need to.

Here is a story of how I did this wrong, and how you can do it right.