bmax

Build. Ship. Customer feedback. That's the loop, and the only thing that matters is how fast you run it.

We ship daily and do quarterly marketing releases. The daily shipping is for us — it's how we learn. The quarterly releases are for the market. Most companies invert this and it kills them. They do quarterly development cycles for themselves and daily updates for marketing. That's backwards.

Chad built our entire Chrome extension solo in about three weeks. We shipped the Dynamics 365 integration in 6 days of actual development. When a critical customer demo needed an account matching fix, we shipped it in hours. Feature flags go live "available tomorrow morning." This isn't heroics. It's the system working.

How the team actually works

Every engineer does a daily standup in Slack. 30 seconds. Three things: what you're shipping today, what's blocking you, how your work impacts others. That's it. No status meetings. No sprint ceremonies. No standups where nine people watch one person talk for twenty minutes.

The development workflow is built around AI. Claude Code is our primary tool. Standard process: planning w/ Claude, break implementation into 4-5 phases, mock and test each phase, end-to-end manual testing. Every PR includes test coverage. PR author is 100% responsible for testing in both staging and production. For broad-impact changes, record a screen recording.

The bottleneck used to be writing code. It's not anymore. The bottleneck is testing, validation, and product judgment. Code generation got commoditized by AI. What didn't get commoditized: knowing what to build and verifying it actually works for the user. Engineers who can't sit in the product seat are going to struggle, because "can we build it" is no longer the hard question.

Two-way doors

Most decisions are two-way doors. You can walk back through them. Implement quickly, iterate based on results. The cost of being wrong on a two-way door is almost always lower than the cost of deliberating about it for a week.

We make one-way door decisions carefully. Database schema changes, pricing models, architecture choices that lock you in. Everything else gets the same treatment: best available option, ship it, learn from real usage.

Time is the denominator

Nat Friedman puts it sharper than I can:

A week is 2% of the year. That's not a fun fact — it's a warning.

Paul Graham said it simply: action produces information. We had a bug in production that cost us thousands in a single day — stale cursor state reprocessing hundreds of thousands of records through our AI pipeline. The team found the root cause and shipped the fix before the weekend. That one day taught us more about our system than the previous two weeks of planning.

We shipped something last winter that, when I looked back at the code a month later, I genuinely didn't recognize as mine. It was ugly. It was rushed. And it was the right call, because the customer feedback we got in those first two weeks completely changed our direction. If we'd spent that month polishing, we would have polished the wrong thing.

The cost is real

I'm not going to pretend speed is free. I've shipped code that made me cringe. Customers have felt pain from changes we pushed too fast. The tradeoffs are real.

But the tradeoff goes the other way too. I'd rather have onboarding problems than no funnel at all. I'd rather have something real in front of a customer than something perfect in a staging environment. No reaction from customers means you didn't move the needle.

Shorten the loop. Everything else follows.