Each day I rewrite my to-do list on paper.

The things I finished get crossed off. The unfinished things get carried forward if they’re worth it.

If it’s worth rewriting, it’s worth doing.

That’s the magic of carry-forward.

First in, first out.

Most tasks get written down and done on day one. A few don’t. The undone things face the rewrite. If they’re worth doing, they get carried forward. If not, they die.

Here’s what I noticed: the longer an idea survives this process, the more it signals importance. It wasn’t done, but it still got carried forward by hand. That friction proves it’s worth doing. The more it gets copied forward, the louder the signal: this needs to get done.

Each day is another filter. It’s natural selection applied to your own ideas. The weak ones fall off. The ones that keep coming back matter.

The manual friction is the feature. If the list auto-populated, there’d be no selection pressure.

This is the same idea behind rewriting my principles. More than a hundred of them, rewritten by hand.

Good ideas persist.

🧪

What task have you carried long enough that it’s time to finish?

I paid $150 for a chef’s knife last week.

A recent trip taught me what a good knife feels like. I knew what $150 would buy.

I could have bought fifteen of the $10 knives next to it. I picked the higher-quality one because I’ll use it every day for decades.

Cost per use drops with each meal. The $150 knife may last twenty years of daily use. The $10 knife I’d replace each year costs $200 over that same stretch. The cheap option costs more over time and comes with less satisfaction per use.

I call these Long-Haul Luxuries. Things you use daily or for long stretches that justify spending more.

More Long-Haul Luxuries:

• A jacket you wear each morning
• Earbuds you wear for hours each day
• A mattress you sleep on for a decade
• A backpack you carry across three continents
• A standing desk you use for eight hours a day

These are Long-Haul Luxuries.

The frame helps me make spending decisions.

Before you buy, ask: how often will I use this and for how long? If the answer is daily and for years, spend toward the ceiling.

🔪

What daily habit would a better tool transform?

Watch

Listen

One move frees you to ship ugly without apologizing for it.

Call it v0.1.

That label changes expectations.

“This is early. It’s rough. But it works.”

The version number handles objections before users can raise them.

V0.1 signals:

• Skateboard stage
• The roadmap is real
• The mess is intentional
• The user joins the process in progress

It also tells you something. If people use v0.1 despite the rough edges, you have signal. If they leave, the value needs work. Now you know.

Version number manages expectations. It gives you permission to ship fast.

🌱

What could you ship today if rough was the point?

Watch

Listen

Last week I caught myself about to make a one-time fix.

I was working on Multi, the tool that turns content into YouTube videos. An agent added a high-priority item to the product backlog. The backlog sorts by arrival time, so the high-priority item landed at the bottom.

My instinct was to drag it to the top. Five seconds, problem solved. But tomorrow another agent adds another item and it sinks to the bottom again.

I fixed the source instead and added a prioritization protocol to the top of the backlog file: priority tiers, ordering rules. Now any agent that touches the backlog reads the protocol and places the item where it belongs.

I did the work once. It pays off each time.

Each problem gives you two options. You can patch the instance or write the protocol that handles each future version.

A patch solves it once. Next time the same problem shows up, you patch again.

A protocol solves the source. Next time the same problem shows up, the protocol handles it automatically.

Rule of thumb: the second time you do something, turn it into a protocol. The first time is discovery. The second time is when you build a rule.

🔮

What’s one repeat problem you could solve at the source?

Watch

Listen

Five years back I asked a small group of founders to try something.

Post a daily standup. Three questions.

• What did you ship yesterday?
• What will you do today?
• Where are you stuck?

Hundreds of founders joined over 2,000 days. They posted 44,110 standups.

The most committed founders wrote the most ordinary first entries.

One founder posted 33 words about finishing newsletter templates. Over the next five years, he posted 1,875 more standups.

Another fixed a bug and wrote “Chilling on Netflix.” 1,813 standups followed.

A founder arrived and mentioned fixing some minor bugs. 1,001 standups followed. Somewhere around entry 500, his product crossed $100,000 ARR. He logged the milestone between a gym session and a Spanish lesson.

On day one, each standup looks the same. A builder shows up, writes what they did and hits submit.

The difference is day two. And day thirty. And day three hundred.

I mined years of standups and wrote a book about it. 2,000 Days of Standups: Building in Public ships April 13 to Trends Pro Members.

🌅

What did you start that looked small then lasted years?

Watch

Listen

I cut a chapter from my habits book today.

The book had 21 chapters. One of them covered moving averages: judging yourself by the trend instead of a single day.

But when I read through the book as a whole, the chapter made it worse by being there.

So I cut it. The book is 20 chapters now. It reads better.

Cutting the good piece can strengthen the whole.

The chapter was good. The book is better without it.

➖

What would your current project look like with 20% less?

Watch

Listen

I went back through a draft and caught one line. “Simple code is easier to build.”

It’s wrong.

Simple code is easier to fix. Easier to read. Easier to maintain. Getting to simple is the hard part.

My first draft of this post had six stories. I kept one.

You add things, then you cut. You rewrite. You ask “is this necessary?” enough times to strip it down.

That takes iterations.

People think simple is easy because the result is easy to understand. Behind it are dozens of drafts and hundreds of cuts.

The simpler it looks, the more work it took.

✂️

Where are you adding when you could be cutting?

Watch

Listen

I ran one command from my terminal and a post showed up on WordPress.

It was rough. Paragraphs ran together. Tweet embeds came through as plain text. The title showed up in the body.

But it went through, end to end. Flawed but real. And now I have something to iterate on.

I could have polished forever. Perfect is always one session away. That version stays in your head. Zero has no surface area. You need something to push against.

Now there’s a non-zero thing to improve.

This is the same logic as the dirty vertical: ship something that works end-to-end, even if it’s rough. Build a wheel, then a frame, then an engine: you get parts. Build a skateboard: you get transportation. Rough everywhere, functional everywhere. It gets iterated into a bike. A bike into a moped.

Last week in my masterminds, the room was stuck. I threw out the worst idea I could think of. Before: nothing. After: five better ones. I’ve started calling the move “taking us to McDonald’s.” The terrible option gives people something to push against.

⚡

What would you ship today if you allowed yourself to ship something rough?

Watch

Listen

I talk a lot about simplicity. Cut what’s unnecessary. Ship the skateboard. Prefer the version with less moving parts.

This week I made Multi’s render pipeline 5x more complex. On purpose.

The old code was clean. Easy to read. Easy to maintain. And slow.

The optimized version is harder to follow, has more moving parts, more edge cases to handle. But it’s faster.

I say simplify to move faster and I still mean it. Simple code is easier to fix and maintain. But I accepted complexity for faster run times.

Unnecessary complexity is adding things that don’t earn their keep.

Justified complexity is adding things that deliver a measurable return.

I traded more moving parts for faster run times.

And I’d do it again.

⚙️

Where would added complexity pay for itself?

Watch

Listen

I left my job in 2017.

People thought I was crazy.

“That is so risky.”

I saw it differently. I ran my own consulting company. One main client, side work when it came. People were still trying to hire me. I could pick up another contract in weeks.

I had two safety nets. Savings that bought me three or four years of runway. And skills the market wanted. The people calling it risky couldn’t see either one.

There was a gap between what they knew and what I knew.

I called it a mini-retirement. Three years off from client work. Jiu Jitsu, reading and biking around Atlanta.

By 2020, money was running low. Either make money or go back to work for someone else.

I built Trends.vc.

Even if I hadn’t, the net was still there. The worst-case scenario had an upside.

I could’ve stayed two more years and reached FIRE through the traditional path. But I would’ve missed years of exploration. I probably wouldn’t have started Trends.vc. I wouldn’t have the network, the product skills or the understanding of how I work best.

It’s almost 10 years later. Companies are cutting engineering roles. The market that couldn’t hire fast enough is contracting. The job I used as my backup plan is under pressure right now.

If I’d stayed, I’d be a software developer in 2026. The skill that was my safety net is accessible to everyone now.

Instead, I spent those years building products, writing and running experiments.

The people calling it risky saw my downside. I saw my options.

The “safe” path was the dangerous one.

🪂

What would your life look like in 10 years if you stay where you are?