The context
Independent consultants sell, in the field, the contracts of some fifteen partners: energy suppliers, telecom operators, insurers. Each partner imposes its own subscription form, eligibility rules, supporting documents and exchange format.
The challenge is not selling itself, it is heterogeneity: adding a partner must not mean rewriting the application, and a change at one must never affect the others.
What I built
Per-partner contract modules
each partner has its own scope: products, bundles, validation rules and documents.
Electronic signature
a signing flow integrated into the subscription funnel.
Document generation and form filling
contracts produced as PDFs, including automatic completion of official forms supplied by partners.
Notifications and campaigns
messages pushed to the consultants' mobile app.
ERP synchronisation
two-way exchange with the group's management software.
Commercial tracking
agreements, client portfolios, history and dashboards.
Architecture & technical decisions
The core of the architecture is separation by partner. The shared trunk handles the client, the consultant and the contract lifecycle; each partner plugs its specifics onto it. That is what allowed new ones to be integrated without destabilising the existing set.
Heavy processing — document generation, mass notifications, ERP synchronisation — is moved out of the request cycle into queues, then broadcast to other services over an event bus. A signed contract emits an event; billing, support and the ERP each react to it independently, with no direct coupling between them.
The application runs on a persistent application server rather than the classic PHP cycle: the framework stays in memory between requests, which noticeably reduces latency for consultants often on mobile networks.
Filling official forms required a dedicated pipeline: partners impose their own PDFs, which have to be populated field by field then merged — a need no HTML rendering library covers.
Technical challenges
Fifteen business logics in one application. Isolate enough that partners do not interfere, factor enough to avoid writing the same code fifteen times.
Consistency across services. The event bus forces asynchronous thinking: a contract may be signed before the ERP has recorded it, and the interface must stay comprehensible in that window.
The field. Mobile consultants, unstable networks, modest devices — hence the attention paid to latency and response size.
Regulated data. Signed contracts, mandates, bank details: regulated information, with access logging and strict bank-identifier validation.
Version upgrades. An application alive for four years crosses several major framework versions, without service interruption.