← Back to articles 2026-04-18

ERPZEN: why you never touch the core

7 min read

Most ERPZEN bugs I get start with the same sentence: "The previous provider modified the core." That is where the real trouble begins. Because at the next update, everything breaks. And I get the call.

The golden rule: do not touch the core

I have worked on ERPZEN for years, and there is one line I never cross: never modify the heart of the application. Everything goes through modules, hooks and clean overrides. Which means your install stays up to date, secure and maintainable — even five years from now, even in someone else's hands.

Editing a file in application/ feels fast. In reality you just signed a debt: the next ERPZEN update will overwrite your file, or worse, keep it and create a silent inconsistency. Either way, it is a support call a few months later.

Why updates break everything

ERPZEN is a living product: security fixes, new features, PHP compatibility. Every version bump replaces core files. If your customization lives in those files, it disappears or conflicts. The only durable customization is the one that lives outside the core.

The clean way: hooks and modules

ERPZEN (CodeIgniter 3) exposes a rich hook system. Instead of patching a view or controller, you hook into it from an isolated module:

// modules/my_module/my_module.php
hooks()->add_action('after_invoice_added', 'my_module_sync_accounting');

function my_module_sync_accounting($invoice_id)
{
    $CI =& get_instance();
    $CI->load->model('my_module/sync_model');
    // Isolated business logic — the core stays untouched.
    $CI->sync_model->push($invoice_id);
}

// Override a view WITHOUT touching the core:
// modules/my_module/views/ + app_init to rewrite the render.

The module is self-contained: you enable it, disable it, move it from one install to another. The core does not even know it exists — which is exactly what we want.

What I take on

Module debugging — yours, marketplace ones, or those left by a previous provider.
Full security audit — OWASP, client data isolation, PHP 8.x compliance, anti-IDOR.
Custom development — HRIS, Factur-X e-invoicing, African payment gateways, sector modules.
Performance optimization — queries, caching, N+1 elimination.
Technical-debt recovery — getting an unmanageable install back on its feet.

My method: no surprises in production

BMAD method, zero regression, file-by-file delivery, validation at every step. Understand the need, model it, design the integration, then write the code. Every module migration is idempotent and reversible. No ERPZEN version bump should ever hold you hostage.

Conclusion

A CRM is an asset. Treating it with discipline — modules, hooks, clean overrides — is the difference between an install that ages well and a time bomb that goes off at every update. If you are looking for someone who codes fast without thinking, I am not the right person. If you want someone who fixes the problem for good, write to me.