Why I built Walden.

Building software used to be expensive. Every line had a cost, the cost was time, and time was a limited resource. The tools we use to manage the work were built for that world.

Agile was a good answer to that problem. A backlog promised that no idea got lost, even the ones there wasn't time for yet. A sprint promised a time block small enough to actually finish, so a team could feel progress instead of just believing in it. A standup promised sync without a meeting eating the morning. These weren't naive ideas. They were reasonable answers to a real constraint, and for a long time they worked.

Making things is not the expensive part anymore, and it gets cheaper every month. The tools didn't update to accommodate this change. A backlog is the clearest case: it used to drain, because you couldn't add to it faster than you worked through it. Now it's infinite by construction, and a tool that helps you manage an infinite list helps you do the wrong thing efficiently.

Velocity has the same problem from the other side. A sprint and a story point were units sized for a world where finishing something took a real, comparable stretch of time, so it was worth stopping to size the work, plan the sprint, and track how it burned down. That overhead was a fair trade when the task itself took days. It stops being a fair trade when the task takes an afternoon. Nothing about estimating gets easier or more accurate; it just stops being worth doing, because the ritual built to manage two weeks of work now costs more than the work.

So the question that used to get asked by default, whether this is worth the weeks it will cost, stopped getting asked because nothing enforces it anymore.

The scarce thing used to be time, now it's judgment. When building is cheap, the only question left is whether to build it at all, and every tool I know is built to answer how fast.

I've seen what that costs for a business. A team I worked with needed a way for new hospital clients to import their inventory data before they could use the product. Normally an engineer just did it for them. Someone proposed a self-serve version, so we built it. It worked: handled what it needed to handle, failed gracefully where it needed to fail. Almost nobody used it. We'd taken the one piece of friction we were removing for people and handed it back to them, and called the result of that a feature. The build wasn't the problem. No one had asked early enough whether it should exist, or if we were even solving for the right pain point.

Shape Up asks these questions. Basecamp's method is built around that one question: Is this worth six weeks of somebody's attention? Everything else follows from there. Work gets shaped before anyone builds it: what it is, what it isn't, kept deliberately rough while the tradeoffs are still cheap to change. Appetite replaces the estimate: not "how long will this take" but "how much is this worth," with the design bending to fit the answer.

A betting table decides, on a fixed cycle, whether shaped work is worth six weeks. Most pitches lose, and losing is the feature: there's no backlog to lose it to. What doesn't win isn't queued; it just isn't built, and if it matters, it comes back on its own. The cycle is a time block with a fixed timeline and variable scope, so scope is what bends. A method built around choosing well, on the understanding that building is what happens after.

And right now, Shape Up has no home. I ran the method inside tools built for something else and felt the mismatch daily. Jira is built for Agile at scale, and it does exactly what it was built to do; its shape is Scrum's shape. Linear is the harder case, fast, considered, well made. You can't blame the mismatch on the craft. But it's organized around the same assumptions. Run Shape Up in either and the drift is always the same: the tool asks its old questions every day until it gets the answers it was built to get, and a season later the team is running Scrum. How that happens deserves an entry of its own.

I wanted something with less friction between the idea and the work, a tool that asked its own question by default, the way the old tools asked theirs. That's most of why Walden exists.

The name comes from Thoreau, who went to the woods to live deliberately, to strip away what wasn't essential and focus on what was left. That's what I wanted from how I worked, not just what I built. Fewer rituals, kept only while they earn their place and contribute meaningfully to the building process. A cycle with a beginning and an end, not a column that never empties.

I don't think every team needs this, and plenty of good work happens inside the tools I'm describing. I built this for people who build for the love of the craft, who care about the thing they're making and want the best possible version of it, not just the fastest one.

This is the first entry. More will follow: on shaping, on betting, on the rhythm of a cycle.