Agerix and project complexity: a structured approach with the Cynefin framework

A well-written specification often gives the impression that the project is clear, structured, and manageable. However, even the most precise requests can reveal a much more fluid reality as soon as we get down to business. For a design office like Agerix, specializing in the development of business applications , this shift between theory and practice is part of everyday life. It requires knowing how to adapt without losing sight of the objectives, maintaining an overview while moving forward in detail.

It is with this in mind that we rely on the Cynefin framework , designed by Dave Snowden .

The Cynefin model is not a typical 2x2 “categorizing” matrix. It is a model that emerges to make sense of existing dimensions, but whose boundaries are sometimes blurred. This is why the lines demarcating the different contexts are not straight. The model distinguishes between “predictable” nature on the right side of the model and “unpredictable” nature on the left.

It is a decision-making tool that allows a situation to be categorized into four areas of action:

• The obvious domain , where the solutions are known and reproducible,
• The complicated area , where expertise allows us to find an answer,
• The complex domain , where answers emerge through experimentation,
• The chaotic domain , where a minimum of order must first be restored before acting.

If you prefer, here is how I could summarize the concept:

Cynefin does not seek to pigeonhole projects, but to shed light on the nature of the problem we are facing in order to better adjust our response. This framework allows us to distinguish what can be planned from what needs to be explored, what can be optimized from what needs to be understood first.

We chose to illustrate this approach with a project we know well: Julie Pujols ‘s website , which offers online content about personal development and Pilates. At first glance, the request seemed simple. It wasn’t. And it’s precisely this type of situation that reveals the value of a framework like Cynefin.

Adapt your posture from the start

When Julie Pujols’s technical team approached us, the request seemed clear: improve the existing system, integrate a store, allow the purchase of video boxes, and connect everything to the Stripe payment gateway . The site was already based on Joomla and the OSMembership Pro component for subscription management. On paper, therefore, it was a matter of enriching a known functional base. Nothing suggested that the project would require a year of development.

Very quickly, we identified a first point of friction. The component in place, although robust for simple membership logic, did not allow us to meet the needs expressed: selling subscriptions, physical products, and video boxes in a single purchasing process. No component on the market allowed such a combination . We therefore had to start from scratch, with a custom development capable of managing several types of objects, different rules, and additional options such as the bundle (subscription + product) or upsell.

This kind of discovery, common in complex projects , requires adjusting the initial posture. We are no longer in a framework where we can plan everything in advance. It becomes necessary to work in iterations, to validate each step, to accept that certain answers will only come along the way. For example, the simple fact of introducing physical products into the purchasing funnel raised unexpected issues: while a subscription only requires a billing address, a physical product requires a delivery address, stock tracking, and shipping rules. What initially seemed like a minor functional addition turned into a complete overhaul of the checkout .

The Cynefin framework takes on its full meaning in these moments. It invites us to recognize that part of the project is entering a zone of uncertainty . This is not a failure of preparation, it is a characteristic of the terrain. Wanting to control everything in this type of context often leads to blockages. Accepting complexity, on the contrary, allows us to maintain a solid trajectory while leaving room for adaptation.

Designing architecture for complexity

The technical challenge: design a single architecture capable of managing objects with divergent logic without compromising the user experience.

Once the management posture has been adjusted, development still needs to follow the same logic. For the Cours de Julie project, the needs expressed affected very different areas : subscriptions, store, video access, payment tunnel, and promotional logic. The difficulty didn’t come from each feature taken in isolation, but from their combination, their interdependencies, and the adjustments necessary to ensure a seamless experience.

The first challenge was to design a system capable of managing objects with very different behaviors in a single cart. The subscription triggers access over time, the physical product must be delivered, the video box opens defined content for a limited time. It wasn’t a matter of stacking modules, but of designing a central logic capable of processing these objects coherently, managing their respective constraints, and interfacing everything with Stripe.

This development required the creation of a custom multi-basket component, designed from the outset to accommodate multiple content types and allow for combinations between them. This was complemented by specific functional building blocks: a thematic video box system, a bundle module combining physical products and subscriptions, an upselling mechanism integrated into the purchasing process, a flexible coupon engine, and complete synchronization of user accounts during the upgrade to the new version of the site.

The Cynefin framework served as our guide throughout these developments. Some features could be specified in detail, broken down, developed, tested, and stabilized. Others, on the contrary, had to be explored, mocked up, tested in real conditions, and adjusted after use. We alternated between these two approaches: rigorous structuring on the one hand, pragmatic prototyping on the other. This wasn’t a methodological choice; it was a natural response to the nature of the problem.

By working this way, we avoided two common pitfalls: wanting to freeze too early an architecture that was not yet mature, and letting complexity set in without a framework. What the Cynefin framework allows is not to simplify the project, but to recognize that not all the building blocks fall under the same category, and that the way they are developed must take this into account.

Thinking about projects and development as a living system

The Julie Pujols project provided an opportunity to observe the extent to which functional, technical, and strategic dimensions are intertwined. On the one hand, it was necessary to fulfill a clear vision: to offer a modern, fluid platform capable of selling subscriptions, video boxes, and physical products. On the other, it was necessary to recognize that this vision involved more winding paths than anticipated. Each decision made on one feature affected another. Each technical addition had an impact on the customer journey. Each constraint encountered redefined the overall balance.

In this context, the Cynefin framework isn’t just an analysis tool. It’s becoming a common language. It helps clients understand why some things move quickly and others take time. It helps structure exchanges between the project team and developers. It reminds us that there’s no opposition between rigor and adaptation, but that we need to know when one takes precedence over the other.

Throughout this project, we navigated between areas of certainty and areas of exploration. Some technical building blocks could be laid directly, with stable specifications. Others required several tests, feedback, adjustments, and sometimes even a complete overhaul. By approaching the project as a living system, by accepting that some answers did not yet exist at the time of design, we were able to build a robust, coherent solution , and above all, one adapted to the reality of use.

This positioning is at the heart of our way of working. It's not about delivering a series of features, but about designing a business application that lasts over time, supports a business model, and remains scalable. The Cynefin framework helps us do this with clarity.

The Agerix point of view

If there’s one thing our experience as a design office has taught us over the years, it’s that there’s no single method for successfully completing a business application project. Some needs are planned, others are tested. Some solutions emerge from the outset, while others emerge over the course of development. What makes the difference is the ability to recognize the nature of the problem you’re facing and to adjust your approach to it.

The Cynefin framework supports us in precisely this process. It doesn’t replace experience or expertise, but it helps us ask the right questions at the right time. Should we follow a procedure? Should we consult experts? Should we experiment? Should we act immediately? This framework allows us to choose the right approach without losing sight of the ultimate goal: delivering a reliable, consistent, and truly useful tool.

At Agerix, we don’t view complexity as an obstacle. We see it as a given to be integrated, decoded, and worked on. It’s this approach that allows us to tackle ambitious projects methodically but without rigidity, rigorously but without fixed certainties.

Frequently Asked Questions

To find out more

If you want to go further into the concept of the Cynefin Framework, I recommend you watch this video where Dave Snowden himself explains what it consists of