Most agencies consider their internal tools a trade secret. We do the opposite: everything we use to manage our 120+ WordPress sites is published openly, on GitHub, readable and downloadable by anyone. Here's why this transparency protects you, what it costs us, and what it brings us.
The standard practice in digital agencies
In the digital agency business, internal tools are traditionally kept secret. Deployment scripts, maintenance automations, CMS extension modules, security processes: all of this stays behind the scenes, presented to the client as "our proprietary method."
The commercial argument is understandable. If you tell everything, your competitors can copy you. If you publish your code, your clients could theoretically take it and do without you. If you document your methods, you make life easier for companies that would like to internalize what you were doing.
This has been the defensive logic of the business for twenty years. And it is also, in our opinion, a logic that does a disservice to the client as much as to the agency.
The invisible problem of the "trade secret"
When you work with an agency whose tools are opaque, you take three risks without always seeing them.
The risk of excessive dependency. If something goes wrong — your agency closes, you change providers, you want to internalize — you discover that no one can take over maintenance, because no one knows how the tools are built. You are captive. This is what is called "vendor lock-in" and it is one of the most costly problems for an SME that wants to grow.
The risk of unverifiable quality. When an agency tells you "we have a solid security chain" or "our backups are infallible", you have no way to verify it. You take it on faith. If it turns out to be false on the day you need it, it is too late.
The risk of stagnation. A team that codes in a vacuum, without external oversight, accumulates errors it no longer sees. Tools go around in circles, sometimes for years, with flaws that no one reports because no one other than the team sees them.
Our choice: everything on the table
When we started structuring our internal tools in 2024, we made a choice that surprised our board: everything that could be public would be. Not just the "showcase" — the entire production code.
Here's what is currently freely accessible in practice:
- The complete code of the system that secures modifications on our WordPress sites (automatic backup, validation, one-click restore)
- The extension modules for the CRMs we install at our clients
- The audit and monitoring tools for our hosting infrastructure
- Deployment scripts, backup procedures, go-live checklists
- The documented methods we apply on every project
All of this is available on GitHub, under a free license, downloadable and usable by anyone. Including our competitors. Including your future providers if you ever decide to change.
What this transparency guarantees you
On the client side, this choice translates into five concrete guarantees.
Independent verification. If we write that "our backups are automatic, validated, and restorable in less than ten seconds", you can ask any third-party developer to verify the code. It is in the public repository, it is readable, it is testable. Verification does not depend on our good faith.
Operational continuity. If we close tomorrow — which we don't wish for, but it can happen — your sites continue to work with the tools already in place, and any provider can take over maintenance by reading the code. You are never blocked.
No hidden costs. When a proprietary internal tool evolves, the agency bills you for the update because you have no choice but to pay to stay compatible. With an open source tool, evolutions are public, their impact is documented, and you can decide with full knowledge.
Easier recruitment on the provider side. Developers joining our team can study our methods before even the first interview. They arrive productive in a few days rather than a few weeks. You benefit from a team that doesn't need to train on obscure in-house tools.
Verifiable reputation. When we write a feedback article like this one, you can verify that the tools mentioned exist, work as described, and are used in production. No hollow marketing slides.
What it costs us
This transparency is not free for us. Here is what we pay for it.
Documentation time. Publishing code usable by others requires careful documentation. Count about 20% extra work time on each published tool, compared to a tool simply used internally. That is real time, which we have chosen to invest.
Exposure to critical scrutiny. When our code is public, flaws are visible. We've been contacted by external developers pointing out bugs or vulnerabilities in our tools. It's unpleasant at the time but invaluable in the long run: we fix issues we'd never have spotted on our own.
A one-off commercial challenge. Some potential clients have asked us, "Why should I pay you if everything is freely accessible?" The answer is in this article: an agency's value isn't in the code, it's in experience, operational responsibility, and the ability to intervene. But this commercial education takes time.
What it brings us
And what it brings us, because nothing is free.
A reputation that builds itself. Our tools are used by other agencies in France, Belgium, and Luxembourg. Every time a developer downloads them, reads the documentation, and appreciates the work, that's a potential recommendation. Several of our current clients came to us this way.
Recruitment in reverse. Developers who like our way of working contact us spontaneously, because they've studied our code and like it. We haven't had to post a job opening in two years.
Stronger internal discipline. Knowing the code will be public forces us to write cleanly. That's a powerful motivator. Our technical team progresses faster because it knows its work is exposed.
A contribution to the ecosystem. We started with WordPress, Elementor, and Perfex CRM, which are themselves open source. Contributing back is a matter of professional ethics, not just commercial calculation.
How to check for yourself
If you want to see concretely what this looks like, you can visit our GitHub organization. You'll find our main tools, their documentation, their change history, and community feedback.
You don't need to be a developer to check the essentials: the regularity of updates (a maintained project publishes often), the quality of documentation (a serious project explains how it works), and responsiveness to reports (real professionals respond when you flag an issue).
Five questions that come up in meetings
If everything is free, can I just grab the code and have my nephew handle maintenance?
Technically, yes. Practically, it's like asking someone who knows how to drive to pilot a plane because they have the manual. Code is the tool, not the skill. What we charge for is experience accumulated over hundreds of cases, the ability to act quickly when something goes wrong, and the operational responsibility of having a site that doesn't go down.
Why don't your competitors do the same?
Probably out of fear of losing their commercial edge, or out of habit. Practices evolve slowly in our sector. And let's be honest, some prefer their clients not be able to verify their technical claims.
My site contains sensitive data. Is it in the public code?
No, absolutely not. Only the tools are public. Your data—articles, contacts, orders, client information—remains strictly in your database and our private backups. The separation is total and audited.
Does that mean my site is less secure since attackers can study your tools?
Actually, it's the opposite. This is what's called the Kerckhoffs principle in cryptography since 1883: a system is more secure when its mechanisms are public, because they're scrutinized and tested by everyone. Security relies on the robustness of the design, not on secrecy. All modern encryption tools (HTTPS, WhatsApp, your bank card) work on this principle.
Does that mean you work less since the code already exists?
On the contrary, we work better. The effort is no longer in constantly reinventing the wheel, but in precise adaptation to your specific case. You benefit from tools matured over years of use — the same rigor that today allows us to deliver sites three times faster with Claude Code, tailored to your particular project.
To go further
Want to understand how our methods could apply to your project? We offer an initial thirty-minute exchange to discuss your needs and identify relevant tools.
Start the conversation on WhatsApp →
Our code is published on github.com/Mogacode-ma et github.com/Mogacode-ma. Downloadable, readable, modifiable.