Why last is a feature
Every hour of custom development is an hour someone maintains forever. It has to survive every upgrade, be understood by every future developer, and be paid for on every migration. So we work a fixed order: standard Odoo first, community modules second, custom code last — and we tell you which tier a requirement landed in and why. When custom work does earn its place, it is because the requirement is genuinely yours: the thing that makes your business your business.
What we build
Modules that extend Odoo where the standard ends. REST and webhook integrations to the systems around it — shops, payment, logistics, IoT. API layers that route orders from Shopify and WooCommerce storefronts into one Odoo fulfilment. The hardware layer that makes a scanner, a customer display and a receipt printer behave as one till. And where the OCA has a module that almost fits, we port it to your version instead of writing a twin.
How it is built
Everything lives in a repository — yours, if you want it there — and reaches production through CI, never by hand. Changes are reviewed before they land and tested against a staging environment first. Before each Odoo release, custom modules are tested against the next version, so the upgrade is a task rather than a surprise. The code belongs to you. That is not a favour; it is how the maintenance problem stays honest.
Development projects in daily use
- Shop integration layer — Shopify and WooCommerce orders flowing into one multi-company Odoo, around 4,000 a day. References →
- Point-of-sale hardware layer — scanner, customer display, printers as one till, eight sites live. The solution →
- Offline field app — React Native, the whole job without a connection. The solution →
- Publishing workflow — manuscript to printed issue to subscription billing, since 2014. References →
What clients ask before development starts
Who owns the code?
You do. It sits in a repository you can take anywhere, with the documentation to make that real rather than theoretical.
What does custom code cost in the long run?
More than its first invoice — every module is retested and, if needed, adapted on every version migration. That ongoing cost is exactly why the cascade exists, and why we will argue you out of custom work the standard can do.
Do you take over code other people wrote?
Yes, after a review. The usual finding is a mix: some modules worth keeping, some replaced by standard features that have caught up, some worth rewriting smaller.
When do you advise against development?
When the requirement is really a process preference in disguise, when an OCA module covers 90 percent, or when the maintenance cost will outweigh the benefit by the second migration. We put that in writing before you spend money on it.
Get in touch
Tell us what isn't working
Send a short description of where your processes hurt. You'll get a reply from the person who would do the work, not a sales team.