Each one says what the problem was, what got built, and the part that was
genuinely hard. Where a client's name is theirs to give out, it is left off
and the work is described instead.
01 · Platform · 2025 to now
A control plane for multi-tenant Odoo
One Odoo database that provisions, hosts and looks after all the others.
The problem
Selling Odoo to small firms falls over on operations. Every customer needs a database, a subdomain, a certificate, backups and an upgrade path, and doing that by hand caps you at about a dozen customers before the weekends disappear.
What got built
A control plane inside Odoo itself: servers, stacks and tenants as records, provisioning from a template database, Cloudflare DNS and proxy host created on the way through, per tenant module sets, scheduled backups, a shell wizard for the jobs that still need a human, and uptime and queue monitoring on every tenant.
The hard part
Everything in it is destructive if it is wrong. The provisioning path had to be idempotent, ordered so a certificate is never requested before its DNS record exists, and safe to re-run against a tenant that is already half built.
02 · Product · 2024 to now
A catalogue of Odoo modules
A hundred and eighty modules on the Odoo app store, written to be sold rather than demonstrated.
The problem
Most Odoo modules on sale do one screen well and fall apart on the second. They ship without tests, without demo data, and with settings that are stored and never read.
What got built
A catalogue built to one standard: real demo data so a buyer can click through an estate, an asset register or a service business on install, a test suite per module, generated listing pages from the manifest so the page can never claim a screen that was never taken, and tooling that audits the whole catalogue for dead settings and missing screenshots.
The hard part
Keeping a hundred and eighty modules installable together on a fresh database, on every Odoo version bump, without a build farm.
A CAFM for hard services, and a second module that runs the contracts it is paid under.
The problem
A facilities firm has two systems in its head: the maintenance one, which everybody buys, and the commercial one, which nobody sells them. They know what a job cost. They do not know whether the contract it sat under made money.
What got built
The estate down to the room, an asset register that carries warranty and criticality, planned maintenance on an interval or a meter, SLA clocks, permit to work, parts issued off the shelf. Then contracts: what is covered, what is chargeable, invoicing on the billing cycle, every hour and part landing against a building and a contract in the ledger, and contract profitability that you can open the jobs behind.
The hard part
Deciding whether a job is inside the cover as it is raised rather than arguing about it at month end, and pricing a subcontracted hour at their cost plus a margin rather than at your own rate, which is how firms sell lift visits below what they pay for them.
Claims, denials, appeals and the coding audit trail, inside Odoo.
The problem
A billing company lives on the gap between what was charged and what was paid. Generic invoicing cannot see that gap, because it has no concept of a payer, a denial code, or a claim that has been resubmitted twice.
What got built
Charge capture, claim lifecycle, payer rules, denial and appeal tracking with reason codes, remittance posting, coding and compliance audits, engagements, and a client portal, delivered in eight phases with a tested upgrade path between them.
The hard part
The upgrade. A billing system is never taken down and rebuilt, so every phase had to migrate the data the last one created.
05 · Product · 2026
Construction ERP with job costing and RA billing
Bills of quantities, running account bills, procurement and the cost sheet that ties them together.
The problem
Construction accounting does not look like any other kind. Work is measured, not shipped; it is billed against a bill of quantities in running account bills; and the cost you care about is committed, not spent.
What got built
BOQ and measurement, RA billing with retention and deductions, material requisition through to purchase order, an eleven role access model with six role dashboards, an approval matrix with a lock and an audit trail, Gantt planning, a job cost sheet that exports, and Arabic throughout.
The hard part
Access control. Eleven roles on a single project, each of which must see the money at a different depth, enforced on the records rather than by hiding a menu.
06 · Client work · 2024 to now
Property portal feeds for Spanish estate agencies
Listings in and out of a dozen portals, in five languages, without a human retyping them.
The problem
An agency in Spain lists on portals that each want a different XML, in a different schema, with different rules about what counts as a photograph. Every one of them fails quietly, and a listing that failed is a listing that is not selling.
What got built
Import and export feeds for the portals the agencies actually use, a hardened parser that says which record failed and why instead of writing an empty batch, image handling that took one filestore from 7.4 GB to 1.1 GB, and machine translation of listing copy into French, Dutch, German and Spanish with the source of truth kept in English.
The hard part
Feeds fail silently by design: the far end returns 200 and drops the record. The work was mostly in making failure loud.
07 · Product · 2026
A restaurant suite that prints on real hardware
Nineteen modules from the menu to the kitchen display, and a print path proven on a thermal printer rather than in a PDF.
The problem
Restaurant modules demo beautifully and then meet a Star TSP143 on a network switch in a kitchen, and nothing comes out.
What got built
Menu and modifiers, order taking, delivery and call centre, a kitchen display, loyalty, branch transfers, and a standalone print module that talks raster to the printer directly rather than going through a PDF and a driver.
The hard part
The printing. It was the reason the suite existed and it is the part that cannot be tested in a browser.
08 · Product · 2026
An HR suite for firms with a fingerprint reader on the wall
Twenty-seven modules, and an attendance path that does not depend on staff being honest about their own timesheets.
The problem
HR software written in San Francisco assumes everybody has a laptop. A factory in Sharjah has a ZKTeco device by the door and three hundred people who never log in.
What got built
Attendance straight off the device, shifts, leave with an approval chain, payroll with a local variant, recruitment, training, travel, service requests, announcements, rewards, and a setup wizard so the first day is an hour rather than a fortnight.
The hard part
Making manual check-in impossible when a device is attached, without breaking the firms that have no device at all.