We ship every Friday (we didn't always)

In part 1, we wrote about why we paused a working platform and rebuilt from zero. This part is about how the build actually runs. And the honest version of that story is not "we ship every Friday." It is "we ship every Friday now, and it took two other ways of working to earn it."

The foundation era: two cycles of six weeks

You cannot sprint on ground that does not exist yet.

The first months of the rebuild ran as two long build cycles, six weeks each. Long cycles were the right shape for that stage, because foundation work does not decompose into week-sized pieces. The architecture, the data model, the principles from part 1 becoming real systems: that work needs uninterrupted depth, and it needs the whole team holding one large problem in their heads at once.

Six weeks is a long time to go without contact with reality. That was the cost, and we paid it deliberately, twice, for the one layer of the product where depth mattered more than feedback.

The middle, where two clocks ran at once

Here is the part these stories usually skip.

While the foundation was being built, we were simultaneously figuring out what the product should be and how it would meet the market. Product direction, positioning, go-to-market angles, all being tested while the ground underneath was still being poured. Two clocks running at different speeds, and everyone could hear both.

We are including this because the clean version of a build story, where process flows neatly from one stage to the next, is a story told backwards. From inside, there was a stretch where the long-cycle rhythm of foundation work and the fast rhythm of finding the product were grinding against each other, and we felt it.

What resolved it was not a better process. It was clarity. The foundation reached the point where it could carry weight, the exploration converged into a roadmap, and suddenly the work changed shape: from open questions to decided features.

The shift to one week

Decided features do not need six weeks. They need five days and no ambiguity.

So the rhythm changed with the work. We moved to one-week sprints: Monday opens on a feature that is already planned and already decided, the week is pure execution, and Friday it ships. Not a demo, not a slide. Something a person can click, break, and argue with.

The lesson we took from the transition is that cadence is not a methodology choice, it is a function of certainty. Low certainty, long cycles, deep work. High certainty, short cycles, relentless shipping. Teams get this wrong in both directions: sprinting through foundation work that needed depth, or crawling through decided features that needed speed.

Lovable, or why 165 versions exist

Now the part of the machine we most want to talk about.

Design in this build does not happen in documents. No discovery workshops that end in sticky notes, no wireframes waiting for review, no polished Figma files handed off to engineering and lost in translation. It happens in Lovable↗, and it is difficult to overstate what that changes.

An idea in the morning is a working interface by the afternoon. Not a mockup, not a clickable prototype pretending to be software. A real, running product surface that our climate analysts can put real scenarios through the same day. Usability testing happens on the actual product, not a simulation of it. Design decisions stopped being debates about descriptions of the product and became reactions to the product itself.

That is where the 165 comes from. In the exploration phase, we produced 165 working versions of what this platform could be. Different flows, different structures, different answers to what carbon accounting software should even look like. Each one real enough to put in front of people. Each one a bet, tested instead of argued.

Run the old math on that number. Each of those bets would have been its own mini design cycle: workshop, wireframe, prototype, feedback round, iteration. The whole exploration would have compressed into maybe five design sprints, with most directions killed in critique before anyone ever touched them, decided on conviction instead of contact. Instead, judgment got applied 165 times against working software. The quality of our decisions did not change. The number of times we got to make them did, and that compounds into a different product.

The handoff, the oldest wound in product work, is simply gone. There is no moment where design intent gets translated into implementation and something is lost, because the design already is the implementation. And that quietly changed who designs. When making a working version costs hours, domain experts stop being reviewers of design and start being authors of it. Some of the versions that shaped this product came from people who would never call themselves designers.

The constant through all of it

Engineers directing agents and owning every outcome that ships. Analysts framing the logic at the first whiteboard and validating the output against an auditor's standard at the end: can this number be traced, recomputed, defended to someone whose job is to doubt it? Those two things never changed across all three eras of the process.

The cadence is how we work. That standard is why the work counts.

Next: the architecture that never moved while everything else did.