← All expertise

02

ERP systems

Odoo shaped around your flows: standard where that is enough, custom where your way of working is an advantage

An ERP is not judged by how many features it has, but by how many people stop keeping a parallel spreadsheet. While that spreadsheet stays open, the project is not finished.

How we take an ERP live
  1. Flow analysisWhat the current system does, and what the spreadsheets kept beside it do
  2. Standard configurationStart from what Odoo already does, without writing code
  3. Custom modulesOnly where your way of working is an advantage, kept in separate modules
  4. Data migrationRehearsed several times, with the numbers having to add up
  5. Go-live by flowStart with the flow that matters most; the rest follows once it really runs
  6. First weeksFixes and side-by-side support: they decide whether the system gets used

Standard while it holds, custom where it counts

Odoo covers a great deal, and every custom module is code to maintain at each upgrade. The rule is simple: customise where the process is the company's competitive advantage, stay on the standard everywhere else.

When customisation is needed it lives in separate, versioned modules rather than edits to the core: that is what keeps the door open to future upgrades.

The numbers you actually decide on

Analytical accounting is the part that pays off most: once costs attach themselves to the job, the site or the product line, margin stops being a year-end estimate and becomes something you watch while the work is still running.

For that to work the data has to be born already assigned — from the phone of the person on site, from the document coming in, from the shift recorded — not reconstructed afterwards from memory.

Go-live without stopping the work

Separate environments for testing and production, database templates to start from a proven configuration, data migration rehearsed several times before the real day, and a way back if something doesn't add up.

On go-live day nobody has to learn everything: you start from the flow that matters most and add the rest once the first one really runs.

Portfolio

What we did on this, project by project.

CocoonServer

Management platform for multi-customer Odoo instances

  • A console governing the environment lifecycle: create, start, upgrade, clone and decommission, with explicit, traced semantics.
  • Per-instance backup and restore with verification and operation history.
  • Custom module and bundle management: upload, package validation and controlled installation on selected instances.
  • Database templates and environment export, so a new customer starts from a proven configuration instead of from scratch.
  • Odoo
  • PostgreSQL
  • Kubernetes
  • Helm
  • Next.js
  • Prisma

ASC Buildings

Construction site wired into analytical accounting

  • Access and attendance captured on site flow into Odoo and become cost on the right job, with no manual re-entry.
  • The data is born already assigned: who entered, where and when, instead of being reconstructed in the back office at month end.
  • Odoo
  • analytical accounting
  • Odoo API
  • Flutter

ERP Next-Gen

Selective port of Odoo onto a TypeScript stack

Internal research: architecture completed, not in production.

  • Portability study of the base module towards NestJS and Prisma: a modular monolith with explicit boundaries and room for future extraction.
  • Multi-company foundation with database-level isolation, cross-module side effects through events, and GDPR requirements taken as a design constraint.
  • NestJS
  • Prisma
  • PostgreSQL
  • RabbitMQ
  • MinIO

Need this?

Tell us the problem and we'll tell you how we would tackle it — and if it isn't worth doing, we'll tell you that too.

Let's talk