How We Ship 70 Releases a Year Across 30 Products

Modular architecture, a shared engineering base across product lines, and why release speed is a matter of how a product is built

In CRM product development, the maturity of a solution is conventionally measured by the volume of functionality: the number of modules, settings, and how long the list of capabilities is. We measure it differently — by the time between the moment a user says something is inconvenient and the moment it is fixed in the live system. This is a different lens, and it changes how development itself is structured.

Over the past 12 months, we released 70 releases across 30 products. Some of them are large functional blocks; most are targeted changes noticed only by someone who works in the system every day. It is this second category that best explains why keeping a high pace matters at all.

A Large Release Is a Year Spent Living With Known Inconveniences

The classic model works like this: a team gathers a backlog, prioritizes it, plans a large release, and ships it once a year. The logic is clear — fewer release cycles, less regression, simpler communication of changes to the market.

The problem is that nine to eighteen months typically pass between the moment a requirement is logged and the moment it is released. During that time, part of the requirements lose relevance: the client’s process changes, the platform changes, the market itself changes. The client lives for a year with an inconvenience the developer already knows about and already knows how to fix.

There is also a purely engineering cost. A large release concentrates risk: the larger the volume of changes bundled together, the wider the regression surface, the longer the UAT, and the more painful the rollback if something goes wrong. Small releases spread that risk over time — and make each individual step reversible.

A Portfolio of Products, Not One Product

Keeping up the pace on one product is an organizational task. Keeping it up across several at once is an architectural one.

We develop several product lines in parallel: a multichannel ecosystem (Multichannel Chats, Multichannel Notifications, Multichannel Bulk Messaging, Multichannel Chatbots, Widget Chat Channel), Data Management, FMCG Management, Project Management, and Questionnaire Management. Each line has its own release cycle and its own audience — from marketing teams to field sales representatives.

Parallel pace is impossible without a shared engineering base. That is why we have a unified release process for all products, a shared integration layer with Creatio, end-to-end regression testing, and strict alignment between product versions and platform versions. When Creatio ships a new version, we do not rewrite each product separately — we update the shared layer.

What Goes Into a Release

Most releases deliberately combine two types of change.

The first is functionality that closes a business need: a new communication channel, a new type of data synchronization, an expanded planning model. This is what shows up in presentations and in Marketplace descriptions.

The second is user experience: a saved filter state, fewer clicks to an action a manager performs forty times a day, a clearer error message. This is what never shows up in a presentation — and what determines whether a user will work in the system voluntarily.

We deliberately do not push this second category off “for later,” once resources free up — resources never free up. So small UX changes travel in the same release stream as functional blocks, and often ship earlier, since they are cheaper to implement and safer to regress.

Speed Is a Property of Architecture, Not a Team’s Pace

A high release frequency cannot be achieved by having the team work more. It can only be achieved by how the product itself is built.

Our solutions are modular: channel connectors are separated from business logic, and processing logic is separated from the interface. Adding a new messenger to the multichannel ecosystem means writing a connector, not rewriting the core.

Creatio’s no-code capabilities and Freedom UI work here as a tool: most client-specific configuration is done by an analyst, not a developer, and it does not require a separate product release.

This is exactly why client customization and product development do not compete for the same resource for us.

Example: A Second Release Before the First Is Even Published

The clearest case is Multichannel Chats. The product is currently being published on the Creatio Marketplace — publication of the first version is still in progress. At the same time, the second release is already ready, and a plan for the third is in place.

This is not a paradox or a marketing figure of speech. Pilot implementations with clients began before publication: real teams were already working with group chats from Telegram, WhatsApp, Viber, Slack, and MS Teams inside Creatio. Feedback from them arrived before the product reached the wider market — and there was time to act on it.

The market will see the first version. Our pilot clients are already working with what will be in the next one.

“We don’t plan a release from a date, we plan it from feedback. If a change is cheap to implement and safe for regression, it goes into the nearest release, not the next quarter. Modular architecture gives us that ability, and it’s a deliberate engineering decision, not a trait of the team’s character.”

— Vladyslav Lytvynchuk, R&D Leader, Sales’Up

What This Gives the Client

Three things that are not visible right away.

Predictability. The client knows their request will not sit in a backlog for a year. The realistic horizon is the nearest or next release, depending on complexity.

No migrations-as-events. Updating a few percent of functionality is routine. Updating thirty percent of functionality is a project with its own budget, testing, and risk. Frequent releases turn the second into the first.

Impact on the roadmap. When the cycle is short, user feedback has a chance to reach the product while it’s still relevant. In an annual cycle, most of those signals simply get lost.

In Closing

Speed has stopped being a characteristic of the team and become a characteristic of the market. Processes in distribution, FMCG, pharma, and financial services are changing faster than a typical annual release cycle can keep up with — not because it’s a bad cycle, but because it’s synchronized to a different pace.

We build products to stay at the client’s pace, not the pace of our own backlog. And we will keep moving in that direction.