Overview
Products often ship late. Despite Gantt charts, sprint planning, and adding resources, the last 10% still takes 90% of the time. Release First is an approach that changes the dynamic.
Read more →📦 Release First ⏩ Ship Faster ⚡
I help product development teams ship predictably by releasing early and often.
Most teams don't discover the real state of their project until it's too late. Release First changes that — giving you clarity, momentum, and schedules you can actually trust.
Sound familiar?
- You're adding 2–3x multipliers to estimates and still missing deadlines.
- You're running standups, filling Jira tickets, and watching burn-down charts — but no one actually knows if you're on track.
- You're not finding out the real state of the project until you're right before the big v1.0 release, with no time to fix it.
- You're watching technical debt compound until development slows to a crawl.
- You're adding more people and more process, and somehow things are getting slower.
Imagine instead...
- Turning around customer requests in weeks, not months — because your team already knows how to ship.
- Responding to a security issue the same day — because you're always current on your dependencies.
- Walking into a schedule review with confidence, because your release history proves your estimates are real.
- Handing off to manufacturing smoothly, because they've been building prototypes from your releases throughout development.
This isn't optimism. It's what happens when you build releasing into the process from day one.
Here's what conventional wisdom gets wrong
Most teams try to manage delivery risk with better planning tools — Gantt charts, sprint velocity, burn-down charts. But these tools measure activity, not progress. They create the illusion of control while the real problems hide underneath.
"Sorry, we can't fix that bug — we don't have the source code."
"Sorry, we can't add that feature — we're out of code space."
"Sorry, it will take 3 months to make that small design change."
Production is down due to sourcing, but we can't modify the design.
The real problem isn't bad estimates. It's that teams build for months before they release anything — and by the time reality shows up, it's too late to respond.
The Release First approach
Before you build anything, figure out how you are going to release it. It's a simple rule with profound consequences. A release is defined by two attributes:
Useful
Others can use it or build on it. Emails, meetings, and demos don't count. A release has a permanent quality that enables others.
Confident
We have high confidence in its quality. Half-done work doesn't count — it's one of the fastest ways to accumulate technical debt.
Release everything — documentation, specs, hardware designs, software, prototypes. The release circle starts small (yourself, co-developers) and widens over time to include marketing, sales, manufacturing, and customers.
Why it works
Expose Reality
There is nowhere to hide. You can't deceive yourself into thinking you're productive just because you sling code or check off tickets.
Drive Feedback
The sooner you release, the sooner you learn what users actually need — before you've spent months building the wrong thing.
Build Automation
The more often you release, the more you invest in automation, testing, and tooling. These investments compound over time.
Burn Down Debt
Releasing forces you to address technical debt early rather than letting it bury you later.
Create Predictability
Frequent shipping produces a track record that makes schedules trustworthy — not just to management, but to you.
Speak a Common Language
A release is something everyone understands — sales, marketing, manufacturing, customers. It replaces status meetings and progress reports with something concrete: working, usable output that speaks for itself.
Common objections
"It costs too much to do all this automation!"
It costs far more to repeatedly do the same things manually, over and over. Automation is an investment that pays dividends every release.
"This will take too long!"
It will be a little slower to start, but investments compound. Without them, technical debt compounds instead — and development speed decays.
Ready to ship with confidence?
I help teams adopt Release First through workshops, assessments, and hands-on coaching. If your team is struggling with predictability, let's talk.
Free Course
New to Git? Start with Git Going.
Git is one of the best tools for releasing consistently — it tracks what changed, when, and why, and makes collaboration and automation far easier. Git Going is a free, hands-on course that teaches version control from scratch — lessons delivered as GitHub issues so you learn by actually using the tools.
- 17 bite-sized lessons at your own pace
- Designed for writers, designers, and developers alike
- Free during beta
About
I'm Cliff Brake, founder of BEC Systems. For over 20 years I've helped companies build and ship connected products — embedded Linux systems, IoT platforms, and cloud-integrated devices — using open source technology.
Release First came out of watching the same patterns play out across dozens of product programs: teams that planned carefully and still shipped late, and teams that shipped early and often and consistently delivered. The difference wasn't talent or tooling. It was the habit of releasing.
My mission is to make that habit the default — so that shipping with confidence becomes a normal part of how teams work, not an exception.