Publication date:
Publication from:
Functionality is a key indicator of a CRM solution’s maturity: modules, settings, and capabilities. But for us, it’s just as important how quickly a user’s request is turned into a change in the live system. That’s why our development process is designed to make this cycle—from feedback to release—as short as possible.
Over the past 12 months, we’ve released 70 updates across 30 products. Some of these are major feature sets, while most are minor tweaks that only those who work with the system daily will notice. And it’s precisely this second category that best explains why we maintain such a fast pace.
The classic model looks like this: the team compiles a backlog, prioritizes it, plans a major release, and launches it once a year. The logic is clear—fewer release cycles mean fewer regressions and make it easier to communicate market changes.
The problem is that nine to eighteen months pass between the time a requirement is finalized and the time it is released. During this time, some requirements become obsolete: the client’s processes change, the platform changes, and the market itself changes. The client lives with an inconvenience for a year—one that the developer is already aware of and knows how to fix.
There’s also a purely engineering cost. A major release concentrates risk: the greater the volume of changes in a single package, the broader the regression test coverage, the longer the UAT, and the more painful the rollback if something goes wrong. Small releases spread this risk out over time—and make each individual step reversible.
Keeping up the pace with a single product is an organizational challenge. Keeping up the pace with several products at once is an architectural challenge.
We’re currently developing 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—ranging from marketing teams to field sales representatives.
Maintaining parallel development pace is impossible without a shared engineering foundation. That’s why we have a unified release process for all products, a shared integration layer with Creatio, end-to-end regression testing, and a strict alignment of product versions with platform versions. When Creatio releases a new version, we don’t rewrite each product separately—we update the shared layer.
In most releases, we deliberately combine two types of changes.
The first is functionality that addresses a business need: a new communication channel, a new type of data synchronization, or an expanded planning model. These are the features that appear in presentations and Marketplace descriptions.
The second is user experience. Saved filter settings. Fewer clicks to perform an action that a manager does forty times a day. Clearer error messages. This is what never makes it into presentations—and what determines whether a user will choose to work in the system voluntarily.
We deliberately do not put off the second category “until later,” when resources become available. Resources never become available. That’s why minor UX changes go into the same release pipeline as feature blocks—and often ship earlier, because they’re cheaper to implement and safer in terms of regression testing.
A high release frequency cannot be achieved simply by having the team work longer hours. It can only be achieved through the way the product is built.
This is clearly illustrated by our multichannel solutions. They are built modularly: channel connectors are separated from the business logic, and the processing logic is separated from the interface. Thanks to this, adding a new messenger to the multichannel ecosystem means writing a connector, not rewriting the core. The no-code capabilities of Creatio and Freedom UI serve as tools here: most of the configuration for a specific client is done by an analyst, not a developer, and this does not require a separate product release.
That is precisely why client customization and product development do not compete for the same resources at our company.
The most telling example is Multichannel Chats. The product is currently being launched on the Creatio Marketplace, and the release of the first version is still underway. At the same time, our second release is already ready, and the plan for the third one has been finalized.
This isn’t a paradox or a marketing gimmick. Pilot implementations with clients began before the public release: real teams were already working with group chats on Telegram, WhatsApp, Viber, Slack, and MS Teams within Creatio. We received feedback from them before the product reached the broader market—and we had time to incorporate it.
The market will see the first version. Our pilot clients are already working with what will be included in the next one.
We don’t plan releases based on dates; we plan them based on feedback. If a change is inexpensive to implement and safe in terms of regression testing, it goes into the next release rather than waiting for the next quarter. Modular architecture gives us this flexibility, and it’s a deliberate engineering decision, not just a trait of our team,
— Mykyta Kalinichenko, Marketplace Leader, Sales’Up.
Three things that aren’t immediately obvious.
Predictability. The client knows their request won’t end up in the backlog for a year. A realistic timeline is the next release or the one after that, depending on complexity.
No major migration events. An update involving a few percent of the functionality is routine. An update involving thirty percent of the functionality is a project with a budget, testing, and risk. Frequent releases turn the latter into the former.
Impact on the roadmap. When the cycle is short, user feedback has a chance to make its way into the product while it’s still relevant. In an annual cycle, most of these signals simply get lost.
Speed is no longer a characteristic of a team; it has become a characteristic of the market. Processes in distribution, FMCG, pharmaceuticals, and financial services are changing faster than a typical annual release cycle can keep up with. A solution that is updated once a year is guaranteed to fall behind—not because it’s bad, but because it’s synchronized with a different pace.
We build products to keep pace with our clients, not with our own backlog. And we’ll continue down this path.
The value of data lies not in its volume, but in how quickly tools can adapt to it. That’s exactly what we focus on in our development.
