Five Releases in Five Days: What We Learned

I remember it was around 11 PM on a Friday when I messaged the dev team: “What about we do 5 releases next week.”

Kamrul, our product manager, came back sarcastically with “2/day will be better bhai.” The team was not convinced and they had a fair reason. We had never done five releases in a single week. Some weeks even one release would slip by a day or two. It was Friday night already and we had no plan, no schedule, nothing.

We said let us just try.

That ended up being one of the best weeks we have had as a team. Things did not all go smoothly, but we figured out something real about how we want to keep building FluentCart from now on.

What we shipped

Five releases, Monday to Friday:

• April 20: Packaging support for physical products and a rebuilt variation editor.
• April 21: EDD Migrator – One-click migration from Easy Digital Downloads to FluentCart, including products, customers, orders, subscriptions and licenses.
• April 22: Amazon S3 overhaul and native Cloudflare R2 support.
• April 23: Advanced Inventory Management with package details surfaced across the buying journey.
• April 24: Browsing History: Full customer journey tracking inside every order, with no third-party scripts needed.

Five release notes published, docs updated for each one, and every release went out to fluentcart.com first

The real problem was not building, it was shipping

I have to be honest about something. Two of those releases (the EDD migrator and the browsing history addon) were already built when the week started. They had been sitting in git for weeks.

The bottleneck was never the code. It was everything around the code.

Our old process worked something like this. A feature would get done, then it would go to two teams at the same time: the marketing team to write the release notes, and the internal testing team to actually test it out. That step alone could take a day or two, depending on what those teams had on their plate. Once it cleared, we would ship. The docs would get updated after the fact, by which point users were already on the new version.

Every step in that flow had a gap, and every gap added days to the timeline.

There was a quality problem on top of all that. Our users open the changelog to find out what actually changed, not how excited we are about it. The people who know the changes best are the developers who built them, and they were not the ones writing the notes.

So when I proposed release week, the point was less about hitting five releases on the calendar and more about giving us a reason to fix the shipping process itself.

The pipeline we built

We put the system together over the weekend and then ran it every day for the next five days.

Code done, then human testing, then deploy to fluentcart.com, then watch FluentLogs in production, then the dev writes the release note, then sync user docs, then sync dev docs, then release on wp.org and pro, then publish the blog post, then a community post, then an email to customers, then watch the feedback come in, then designate tomorrow’s release lead, then sleep.

One thing worth explaining is that the human testing does not happen only at the end. Every pull request gets human tested before it gets merged, in parallel with development. By the time the code is actually ready to ship, most of the testing has already been done along the way. That is how the pipeline can move quickly without cutting corners.

Around 150 pull requests went through this process across the week.

Two parts of the new pipeline are bigger changes than they look on paper.

First, docs come before release now, not after. We flipped this completely. Documentation used to get updated after users were already on the new version. Now if the docs are not ready, the release simply does not go out. That means dev, docs, and release all have to land on the same day, which is harder to coordinate but is also the right way to do it.

Second, the developers write the release notes themselves. The person who built the feature is the person who knows which edge cases got handled, what decisions were made along the way, and what users need to understand to actually get value out of it. A first draft from the dev who built it is closer to reality than a polished marketing rewrite, and our users can tell.

Why we deploy to ourselves first

We originally built FluentLogs as a log monitoring service for PHP errors and notices in production. The reason it works for us is that fluentcart.com (our own store) is our first production environment. Before anything goes to wp.org or to our pro customers, it runs on us first.

This sounds obvious but it is not that common in our space. Plenty of teams ship from staging straight to their customers and find out about the problems through support tickets.

On the local side, every developer has debug logging enabled with a desktop notifier that fires the moment an error log is thrown. We run static analysis and tests on every change. By the time the code reaches fluentcart.com, it has already been through several rounds of checking.

FluentLogs is the final layer. During release week it caught a few PHP notices in production, none of them critical, because the earlier layers had already caught the real issues. That is what you want from a production monitor: a safety net for things that managed to slip through, not the first place you find out you have a bug.

The hardest day was the EDD migration

Not all five releases were the same weight.

For something like a redesigned variation editor or adding Cloudflare R2 support, if something goes wrong you can patch it quickly and most users barely notice.

The EDD migrator was a completely different category.

A lot of stores have their entire business running on Easy Digital Downloads, and our migrator was promising to move everything in one pipeline (products, customers, orders, subscriptions, software licenses) without any downtime and without breaking the customer’s site.

We ran it on real EDD stores before release day. We hit edge cases, the kind you only find on actual data with years of accumulated weirdness, and we fixed them and ran it again.

The day it shipped was the most careful day of the week. When real stores ended up migrating cleanly with their licenses still intact and their subscriptions still billing, that was when the whole week felt worth it to me.

What the team actually felt

The first two days were full of doubt. We were doing something none of us had done before. The quiet question underneath everything was whether we were cutting corners to hit a schedule we had invented on a Friday night.

The system did not allow that. If the docs were not ready, the release did not go. If FluentLogs flagged something in production, we fixed it before publishing. Any shortcut anyone tried to take eventually showed up somewhere later in the process.

By Wednesday the rhythm had clicked. People knew their role. Each day I would designate a different release lead and tell them the night before. That one change made the biggest difference of the week. Each day a different person owned the release from start to finish, instead of waiting for me to coordinate the docs or run the checklist for them.

And nobody worked the weekend. Five releases, Monday to Friday, in normal hours. That part really matters to me. The point is not to grind people into hitting a schedule once, it is to build a team that can keep doing this kind of week without it costing them their evenings.

By Friday, Kamrul (the same one who had been sarcastic on Friday night) was running the release himself.

What this taught us about how we want to build

The biggest thing I am taking away is that we had been carrying months of friction in our shipping process without really noticing it, and one week of focused effort was enough to clear most of it out.

Every feature we shipped this week (packaging support, advanced inventory, full customer journey tracking inside the order view, S3 & Cloudflare R2 storage with a proper setup wizard) is something we decided belongs in the product by default. Not in a higher tier and not behind an addon that costs hundreds of dollars a year and unlocks a single screen.

The browsing history addon is a good example of how we think about this. You can now see the full path a customer took before they bought (which pages they read, how long they spent, where they came from) directly inside the order view, next to the order that behaviour influenced. That kind of visibility used to require stitching together data from a few different tools and a fair bit of guesswork.

When we are deciding whether to build something, the first question we ask ourselves is where it needs to live to be useful, not what we could charge extra for it.

Release week was us proving to ourselves that we can keep up with this kind of pace without breaking things and without breaking the team in the process.

We have a lot more we want to build, and the machine that ships it is now working the way it should.