Building a White-Label Product on Mautic: What We Learned Customizing the Core

Mautic is one of the most powerful open-source marketing automation platforms available. It handles contacts, segments, campaigns, email sending, landing pages, and reporting out of the box. But out of the box, it looks and feels like Mautic. The logo says Mautic. The interface says Mautic. Every screen reminds you that you're using someone else's software.

Our client didn't want their customers to know they were using Mautic. They wanted a commercial SaaS product - their brand, their interface, their workflow, their product. Mautic would be the engine underneath, completely invisible to end users.

We turned Mautic into that product. Here's what it took, what we learned, and the architectural decisions that made the difference between a fragile hack and a maintainable platform.

What "White-Label" Actually Means

Let's be clear about what we're describing, because "white-labeling" means different things to different people.

This was not a CSS theme swap. It was not replacing a logo and calling it done. It was a comprehensive product transformation:

• Complete visual rebrand. Every screen, every modal, every notification carries the client's brand. Colors, typography, icons, logo - all custom. A user logging into the platform would never guess Mautic exists underneath.
• Reorganized menu structure. Mautic's default navigation is built for Mautic power users. Our client's customers have different workflows, different priorities. We restructured the menu hierarchy to match the product's UX patterns - hiding features that don't apply, promoting the ones that matter most.
• Custom dashboard. The default Mautic dashboard shows generic marketing metrics. We built a custom dashboard focused on the specific KPIs relevant to the client's use case, surfacing the data their customers actually need.
• Removed and hidden features. Not every Mautic capability is relevant to every product. Features that would confuse users or complicate the interface were hidden or removed entirely.

The result: end users interact with what feels like a purpose-built marketing automation tool. They never encounter Mautic's branding, never see features meant for a different audience, never feel like they're using a generic open-source tool that's been lightly reskinned.

The Custom Email Builder: 4 Dynamic Block Types

The most significant customization - and the one our client's customers interact with most - is a custom email builder plugin that replaced Mautic's default editor entirely.

Mautic ships with an email builder. It works. But for our client's use case - organizations with multiple branches, locations, or divisions that need to send personalized content at the branch level - the default builder's dynamic content capabilities weren't sufficient.

We built a custom builder plugin with four dynamic block types designed specifically for branch-level personalization:

Dynamic Image. A block that displays different images based on recipient conditions. A library system with 20 branches can include a photo of each branch's building - the recipient sees their local branch, not a generic stock photo. The editor opens a modal where the content creator selects the condition (which branch?), chooses the image for each variant, and the builder handles the rest.

Dynamic HTML. For complex content that goes beyond simple text and images. Branch-specific opening hours formatted as a styled table. Location-specific event calendars. Custom HTML snippets that change per segment. The content creator works in a visual editor while the builder manages the conditional logic underneath.

Dynamic Button. Call-to-action buttons that change their text, URL, and styling based on conditions. "Visit your local branch" pointing to different Google Maps links per location. "Register for the event" linking to different registration pages per city. Same email, different actions per recipient.

Dynamic Text. Personalized text blocks that swap content based on recipient attributes. Different greeting styles per region. Different contact information per branch. Different promotional copy per segment.

Each block type integrates with Mautic's dynamic content system. When a content creator adds a dynamic block, a modal opens for condition setup. They can define condition groups - "if the contact belongs to Branch A, show this; if Branch B, show that; default to this." The conditions leverage Mautic's existing segment and contact field infrastructure, so there's no separate rules engine to maintain.

The builder works for both emails and landing pages. One plugin, two contexts. A content creator builds a personalized email with branch-specific blocks, then builds a matching landing page with the same dynamic block types and the same condition system. Consistent experience across channels.

Beyond the dynamic blocks, the builder includes custom presets, block cloning, and reusable custom blocks that content creators can save and reuse across campaigns. These quality-of-life features matter - they're the difference between a tool that's technically capable and one that people actually enjoy using.

Template Management: Extend, Don't Hardcode

This is the architectural decision that saved us the most pain during upgrades, and it's the advice we'd give to anyone customizing Mautic at this depth.

Never replace Mautic's core templates. Extend them.

Mautic's template system supports extension - you can override specific template blocks without replacing the entire file. When we needed to change how the dashboard renders, we didn't copy the dashboard template and edit it. We created an extension that overrides only the blocks we need to change.

Why this matters: when Mautic releases a new version, the base templates change. If you've replaced them entirely with hardcoded copies, you need to manually merge every upstream change into your custom templates. If you've extended them, the upstream changes flow through automatically - your extensions stay on top, modifying only what they need to.

Compiled assets (JavaScript bundles, CSS files) are managed through a defined build process. We have a clear pipeline: source files go in, compiled assets come out, and the build process is documented and reproducible. No manual compilation, no "it works on my machine" situations.

This approach was validated during our Mautic 5 to 6 upgrade. The new version brought significant UI changes, and while we still had work to do, our extension-based approach meant we were fixing targeted overrides rather than doing wholesale template rewrites. The investment in proper architecture paid for itself.

Configuration Hardcoding: When the Admin UI Is the Enemy

Here's a philosophy that might seem counterintuitive: for production-critical settings, we deliberately remove the ability to change them through the admin interface.

Our platform uses Amazon SQS for queue processing. The SQS connection strings, queue names, and transport configuration are critical infrastructure settings. If an admin accidentally changes a queue name through Mautic's settings UI, email processing stops for that tenant. In a multi-tenant environment, a single misconfigured setting can cascade.

So we hardcoded these settings in the application code. They're defined in configuration files that are part of the deployment, not in the database where the admin UI reads and writes them. The admin interface still shows the settings page - but the values are enforced by the codebase, not by what's stored in the database.

As our lead developer put it: the settings are "killed in code." Even if someone sits in the admin panel and tries to change them, the hardcoded values take precedence. The configuration is part of the application, not part of the instance's mutable state.

This approach extends beyond queue settings. Any configuration that should never change in production - SMTP settings, API integrations, caching configuration - is enforced at the code level. The admin UI remains useful for settings that genuinely need to be tenant-configurable (branding options, notification preferences), while infrastructure settings are locked down.

Lessons from Heavy Mautic Customization

After building and maintaining this white-label product through multiple Mautic versions, here's what we've learned:

Understand Mautic's plugin architecture before touching anything. Mautic has a well-defined plugin system. Many customizations that seem to require core modifications can actually be achieved through plugins. We built the email builder as a plugin, not a core patch. This keeps our customizations cleanly separated from Mautic's code and makes upgrades dramatically simpler.

Keep customizations modular and isolated. Our email builder plugin doesn't depend on our dashboard customization. Our menu restructuring doesn't depend on our configuration hardcoding. Each customization is an independent module that can be developed, tested, and updated separately. When one module has issues during an upgrade, the others continue working.

Document every customization point. We maintain documentation of every place our code touches Mautic's default behavior - every template extension, every overridden service, every configuration override. When a new Mautic version drops, this inventory is the starting point for the upgrade assessment. Without it, you're grepping through code trying to remember what you changed and why.

Test upgrade paths early. We don't wait for a Mautic release to drop and then scramble. When release candidates are available, we test our customizations against them. Early testing means early identification of breaking changes, and time to plan rather than panic.

When White-Labeling Mautic Makes Sense

White-labeling Mautic is a significant engineering investment. It makes sense when:

• You're building a SaaS product where marketing automation is a core feature, not when you just need to send a few campaigns internally.
• Brand control matters - your customers expect a cohesive product experience, not an obviously reskinned open-source tool.
• You need customization depth that goes beyond themes and plugins available in the Mautic marketplace.
• You have engineering capacity to maintain customizations through upgrades. This isn't a set-it-and-forget-it project.

The result of our work: a production SaaS product that the client is actively selling to organizations across the country. Built on open-source foundations, with custom engineering that turns a general-purpose tool into a specialized product. That's the promise of open source - and the engineering effort required to deliver on it.

Considering Mautic for Your Product?

If you're evaluating Mautic as the foundation for a commercial product, or you need deep customization of the platform for your organization's specific needs, we can help. We've navigated the entire journey - from initial assessment through white-labeling, custom plugin development, and ongoing maintenance across major version upgrades.

[Book a free consultation](https://www.droptica.com/contact/) to discuss your Mautic customization needs.