Perfex CRM Development · Modules
Custom Perfex modules that survive your next update.
Every Perfex install eventually needs something the core does not do. The question is only whether that feature arrives as a proper module or as an edit buried in a core file — because one of those choices quietly ends your ability to upgrade.
Fixed written quote within 48 hours · staging first · documented handover
The fork in the road
Core Edit vs Module
Both approaches make the feature work on the day it ships. Only one of them is still working after your next Perfex update — and the difference is invisible until the moment it costs you.
Anatomy
What a Properly Built Module Contains
Its own tables
Data lives in module-owned tables created on install with the right prefix, never bolted onto core tables where an update can collide with it.
Its own settings screen
Configuration your admin can change without a developer — API keys, toggles, defaults — stored in the options table like every other Perfex setting.
Its own permissions
Staff roles decide who can see and change what the module does, using Perfex's own permission system rather than a parallel one nobody audits.
Its own language files
Every string translatable, so the module speaks whatever language your install does instead of hardcoding English into your CRM.
Hooks, not edits
The module listens to Perfex events and adds behaviour through the hook system — which is exactly why a core update cannot erase it.
A clean uninstall
It can be removed and leave nothing behind but your data, if you want it. Software you cannot remove is software you do not own.
Two we built
Modules Running in Production
Payments bridge
An authenticated API that records payments against invoices idempotently — a gateway can retry the same webhook ten times and the payment books once. It writes through Perfex's own models rather than straight into the database, so invoice status, the activity log, and the after-payment hooks fire exactly as they would for a payment entered by hand.
Meta lead-ads integration
Written from scratch to replace an abandoned third-party module. Signed webhooks verified on arrival, tokens encrypted at rest, fields mapped to your lead form, duplicates handled — plus a cron sweep with a deliberate overlap window, so a webhook Meta failed to deliver still lands as a lead instead of vanishing.
Neither edits a core file or alters a core table. Both run in VoltsCRM, the Perfex-based platform our own agency runs on — which is the short version of why we build this way.
FAQ
Module Questions, Answered
A self-contained package that adds features to Perfex without touching the core: its own database tables, settings screen, staff permissions, language files, and menu entries. It installs and uninstalls cleanly, and a core update rolls straight past it.
It is faster once, and then it costs you forever. The next Perfex update overwrites your changes, so you either lose the customization or stop updating — which means stopping security patches. Every hour saved by editing core is borrowed against an upgrade you will eventually need.
Yes, and it should. A properly built module creates its tables on install with the correct prefix, so it works in single-tenant and multi-tenant installs alike, and removes them on uninstall if you want it gone.
That is the entire design goal. Because nothing in core is modified, upgrades apply normally. We test modules against the Perfex version you run, and where an upgrade genuinely changes an interface we depend on, that is a small maintenance update rather than a rebuild.
Often, yes. The first step is a short audit of what exists and whether it touched core. Sometimes it is cheaper to finish it, sometimes cheaper to rewrite it properly — and we will tell you which, including when the answer costs us the bigger project.
Collaboration
Got a project?
Let's talk.
We're a team of creatives who are excited about unique ideas and help companies to create amazing identity by crafting top-notch UI/UX.