It wasn’t that Divi didn’t offer enough responsive options. Divi already provides many settings for adjusting typography, spacing and layout across different device sizes.
The challenge was repetition. The same decisions had to be made in every project, across pages and modules. Font sizes needed responsive values. Sections and Rows needed consistent spacing. Content widths had to work from mobile devices to large desktop screens. Menus, forms, sidebars and footer widgets often required their own adjustments.
All of this can be done by hand. But as a project grows, it becomes increasingly difficult to keep every value aligned. Small inconsistencies accumulate, and changes that should affect the whole design turn into a long list of individual corrections.
Defining the Values Wasn’t the Difficult Part
Our initial aim was straightforward: create fluid typography and spacing scales based on a few minimum and maximum values.
Instead of defining separate values for mobile, tablet and desktop screens, fluid values adapt continuously to the available screen width. The same principle can be applied to font sizes, spacing, Section rhythm and Row dimensions.
Producing those values, however, was only half of the solution.
A set of variables does not become a working design system until those variables are applied in the right places. Someone still has to decide which value belongs to a heading, a button, a form field or a particular spacing role—and then repeat those assignments throughout the website.
This became the central idea behind Fluid Base for Divi: the plugin should not only generate fluid values, but also apply them where they are actually needed.
Applying a System Without Taking Away Control
The next challenge was applying values automatically without getting in the way of designers who wanted to make local adjustments.
Fluid Base values should provide sensible defaults. Designers should still be able to override those defaults, detach individual controls from the system or deliberately clear a value.
A value that has not been configured yet is not the same as one that someone intentionally changed. An automatic system has to understand that difference, or it eventually begins to work against the person using it.
A substantial part of the development therefore went into separating plugin-controlled defaults from user-controlled values. Copied modules, saved layouts and existing pages need to retain their intended settings. Imports and resets must produce a coherent result without disturbing unrelated choices. Repair functions should restore missing connections without silently rewriting the design.
This work is less visible than adding new controls, but it became one of the most important parts of Fluid Base. Automation is only useful while it remains predictable.
Divi 4 and Divi 5 Required Different Approaches
Supporting both Divi 4 and Divi 5 added another major development challenge.
Divi 5 has a native variable system. Fluid Base can create font-size and spacing variables that become part of the normal Builder workflow. This is the more direct approach, but it also requires careful synchronization between generated variables, their assignments and local Builder values.
Divi 4 does not have the same variable architecture. Fluid Base therefore uses optimized CSS to create a similar responsive foundation on the frontend.
The objective is largely the same in both versions, but the mechanisms are different. Supporting both properly meant respecting those differences instead of forcing them through one technical solution.
From Fluid Scales to a Project-Wide Foundation
The first development steps focused primarily on fluid typography and spacing. As we applied the system to complete websites, it became clear that these areas could not be treated in isolation.
Typography affects line lengths, module dimensions and vertical rhythm. Section spacing determines the pace of a page. Row widths influence how typography and spacing feel across different screens. Module defaults determine whether a newly added element begins inside the system or immediately introduces another exception.
The scope therefore expanded to include Section and Row rhythm, layout widths, module defaults and more detailed control over where generated values should be applied.
We also had to look beyond ordinary Builder layouts. Real websites include classic WordPress content, sidebars, footer widgets, search results and other areas that may not have been rebuilt with the Theme Builder. WooCommerce and Contact Form 7 add further contexts that should still feel connected to the rest of the website.
Reusable presets, import and export functions followed the same reasoning. Once a design foundation has been established, it should be possible to reuse it without rebuilding the entire configuration.
Fluid Base gradually developed from a generator for responsive values into a foundation intended to support a complete Divi project.
Real Projects Changed Our Priorities
A feature may work correctly on a clean test page and still behave differently when it meets an existing website, copied Builder content, an older theme structure or another extension.
Real projects contain a mixture of current and historical decisions. They are rarely as tidy as an empty installation.
Later development therefore focused increasingly on boundaries and exceptions: when Fluid Base should apply a value, when an existing value must remain untouched and when a feature should be limited to a particular context.
Some changes expanded the system. Others narrowed behaviour that had initially been too broad. In several cases, the right improvement was not making Fluid Base do more, but teaching it more precisely when to do nothing.
Reliability and Performance Became Part of the Product
As the number of supported areas grew, reliability and performance became more important.
Fluid Base has to coordinate plugin settings, Divi values, Builder content and frontend output. These parts can change at different times, so the plugin needs to keep them aligned without repeating unnecessary work or losing pending changes.
We spent considerable time reducing repeated processing, improving caching and making synchronization more dependable. We also reviewed what happens when a process cannot complete successfully. A task should not report success simply because a request finished; the intended change must actually have been applied.
We also tested performance ideas that we deliberately decided not to use. Some architectural changes sounded efficient in theory but provided no meaningful benefit under realistic conditions. Adding complexity without a measurable result would only have made the plugin harder to maintain.
That became another important development principle: performance should be measured rather than assumed.
What We Have Learned About Divi Extensions
Having worked with WordPress for well over a decade, we understand the hesitation around extensions.
A plugin may look useful on paper but introduce side effects, impose a separate workflow or create another layer of corrections. Developing Fluid Base reinforced the importance of respecting Divi’s existing concepts.
The Visual Builder should remain the primary workspace. Divi’s native systems should be used where they provide the right mechanism. Local values should remain authoritative. A feature should affect only the context it was designed for.
We cannot test every third-party Divi extension individually. Non-native modules also do not receive the same dedicated Per-Module Fluid Base controls as native Divi modules. In Divi 5, however, Fluid Base variables can still be used in compatible fields provided by other extensions.
Rather than thinking of Fluid Base as a list of features, it may be more accurate to think of it as a series of boundaries: where a value should be applied, where it should be left alone, what belongs to the plugin and what remains under the designer’s control.
A Foundation, Not Autopilot
Fluid Base will not replace visual judgment or make every design decision automatically.
There will still be times when a headline should be larger, a Section needs different spacing or a deliberate exception makes the composition work better.
What Fluid Base can do is remove much of the repetitive work underneath those decisions. Typography, spacing and layout begin with the same system. New modules receive useful defaults. Classic WordPress content can follow the same visual logic as Builder layouts. Intentional exceptions remain possible.
That is why we continued developing Fluid Base after the original fluid scales were working. Calculating responsive values was the straightforward part. The difficult part was turning them into a dependable foundation for real Divi projects without taking control away from the people building them.