Custom Development

ERP & operations

Odoo (Community and Enterprise), Dolibarr, ERPNext

The starting point is nearly always the same: purchasing lives in one spreadsheet, stock in another, and invoicing is retyped by hand from both. We begin by mapping what is already there — the files, the unwritten rules, the habits holding it together — before choosing the foundation. We configure purchasing, stock, production and invoicing, carry the history across instead of starting from nothing, and build the modules your business needs and the standard ignores, as with a training centre ERP or a warehouse management system. The result: data entered once travels, and the gap between recorded and actual stock becomes visible rather than being discovered at month end.

E-commerce

PrestaShop, Magento (Open Source and Adobe Commerce)

We are rarely called to open a shop; we are called because a shop exists and lives apart from everything else. Displayed stock is not real stock, orders are recopied into the back office, and nobody can say where an order stands without opening three screens. We wire the shop into the operational core, put order orchestration in place once channels multiply, and separate the storefront from the sales engine where performance or a redesign calls for it — the thinking behind decoupled sales platforms and marketplace infrastructure. What changes: the site stops being an island, and your team stops retyping.

CRM

SuiteCRM, Vtiger

The trigger is almost always a departure: a salesperson leaves and their contact book goes with them, because it lived in their mailbox. We gather contacts wherever they sit — mail, spreadsheets, an abandoned tool — de-duplicate them, and configure a follow-up that fits your sales cycle instead of imposing its own. We then connect the CRM to invoicing and to the catalogue so that a quotation is generated from real data, and open a customer portal where the follow-up needs to be shared. Long cycles involving several people, such as automotive lead management, need assignment rules that we write with you.

Content & data

WordPress, Drupal, Pimcore, Strapi

The tipping point comes when the catalogue becomes unmanageable: the same product exists in three versions — on the site, in the ERP, in a sales spreadsheet — and none of them is right. We then separate the repository from its presentation. The product repository becomes the single source, maintained by the people who know the products; the site consumes that source instead of duplicating it. Depending on volume and channels, we either stay on a conventional editorial platform or move to a decoupled architecture, as with a BtoB catalogue behind an institutional site. What changes: you correct a product record in one place.

Audience measurement

Matomo, Google Analytics

The question comes up when a budget has to be decided and nobody knows what visitors actually do. We set the measurement plan before the tool: which decisions need evidence, and therefore which events are worth tracking. The choice between the two turns on your data constraints — Matomo is hosted on your own infrastructure and keeps the records under your control, which settles the question of transfers outside Europe; Google Analytics makes sense when your campaigns are already tied to it. We install it, check that what is being counted is what you think is being counted, and build the views you will genuinely look at.

Workplace

Microsoft 365

You already have it, and it sits alongside the business system: people sign in twice, documents travel as attachments, and leavers are handled by deleting accounts one at a time. We wire up authentication so a single account opens the right doors, connect mail to the applications that need to send, and back employee portals onto the directory rather than a list kept on the side. Where a unified HR repository exists, it becomes the source for joiners and leavers. What changes: access follows people, with no manual step.

Custom development, business components and modules

There is always a part no catalogue covers, and it is often the part that sets you apart: a pricing rule only you apply, a calculation inherited from your trade, a regulatory constraint specific to your sector. We write it as a component grafted onto the chosen foundation, never as a fork of the product — an interactive configurator, a promotional rule engine, a routing and route planning engine. The rule we hold ourselves to: the foundation must stay updatable, and our work must never stand in the way of that.

System interconnection

The need appears when two perfectly good tools have to share the same data without anyone retyping it. We map the existing flows, decide which system is authoritative for which data — the question that settles everything else — then build the exchanges and the error handling, because a flow that fails silently is worse than no flow at all. This is the work behind urbanising a core banking system, clinical systems interoperability and BIM-based construction site monitoring. What changes: the tools stay, the double entry goes.