Skip to content
← BACK TO JOURNAL
SHIPPING . APR 02 . 5 MIN

14 builds a week. What that actually feels like.

BB
Braeden Bihag

A "build" at Almost a Lab is a tagged release build, not a finished product. That distinction is the whole story. We ship 14+ tagged release builds a week, across projects, and we have logged 5,000+ commits across our GitHub in the last twelve months. Two founders. No team of forty. The number sounds like marketing until you understand it counts releases, the moments a thing actually goes out, not features or ideas or screenshots in a deck.

What a build is, and what it is not

A build is a tagged release that lands on a reachable URL. That is the bar. If a pull request merges and the result is not something you can open in a browser, it does not count. We do not count prototypes. We do not count branches that died in review. We do not count the clever thing one of us wrote on a Saturday that never shipped.

So 14 a week is not 14 products a week. Most weeks it is two or three projects each moving forward several releases. A build can be a pricing page that finally renders correctly on Safari. It can be a recovery path for a blocked site that now works end to end. The point is the same every time: it is live, and someone could use it the minute it tags.

The engine under this is ImpossibleOS, our internal deployment backbone. It is the reason a release is cheap to cut. Every PR has a path to production already wired. We did not bolt deployment on at the end. It is the floor we stand on, which is why the friction of shipping is close to zero and the friction has moved entirely to deciding what is worth shipping.

Production from day one, and the graveyard we refuse to build

Every PR lands on a reachable URL. We decided early that we would not keep a prototype graveyard. You know the kind. Forty half-finished repos, each one a small monument to a week that felt productive and produced nothing you could point a person at. We have none of those. If we start something, the first thing we build is the path that gets it live, even ugly, even thin.

This changes what "done" means. Done is not the demo. Done is the tag. A thing is not real here until it has a URL, and that rule has saved us from more bad ideas than any planning meeting ever did. When you have to ship it, you find out in two days whether it deserves to exist. Most do not. We kill those fast, and the killing is cheap because we never poured a month into them first.

The honest cost

Now the part nobody puts in the velocity post. This pace cuts real things, and I am not going to pretend it does not.

  • Polish gets cut. A build that works ships before a build that is beautiful. We come back for the polish, but "come back" is a promise, and some weeks it slips.
  • Documentation gets cut. The code is the truth more often than I would like. Two founders can hold a lot in their heads, and we lean on that harder than we should.
  • Big architecture rewrites get deferred. When shipping is this cheap, you patch instead of rebuild. Debt accrues. We pay it down in deliberate sprints, not continuously.
  • Saying no gets harder. Every reachable URL is a small invitation to keep going on the wrong thing.

Monday does not start with a roadmap review. It starts with looking at what tagged over the weekend, what broke, and what the two of us actually want to be true by Friday. The plan is short because the feedback loop is short. We are rarely planning more than a week out, and that is a real limitation, not a virtue I am dressing up.

And the weekends. I will be straight about this. The 5,000 commits did not all happen between nine and six. Some of that velocity is two people who like building things and do not always switch it off. That is a choice we made, with eyes open, and it is not a model I would hand to someone and call sustainable without saying out loud what it costs. It works for two founders at this stage. It is not a law of nature, and it is not advice.

Done is not the demo. Done is the tag. A thing is not real here until it has a URL.

So when you see "14 builds a week," read it as 14 tagged releases that are live, from two people, on a backbone built to make shipping the easy part. Not 14 products. Not 14 miracles. Just a discipline that trades polish and rest for the certainty that what we make exists in the world by the end of the week.

// frequently asked
Is a "build" a finished product?

No. A build is a single tagged release build that lands on a reachable URL. Fourteen a week is mostly two or three projects each moving several releases forward, not fourteen separate products.

How do two founders ship at that rate?

ImpossibleOS, our internal deployment backbone, makes cutting a release cheap because every PR already has a path to production. The friction is in deciding what to ship, not in shipping it. It also takes weekend work, which we are honest about.

What gets sacrificed for this velocity?

Polish, documentation, and large architecture rewrites get deferred, and saying no gets harder. We pay down debt in deliberate sprints rather than continuously, and we are clear-eyed that the pace leans on two founders and their weekends.


Brief a build →