The architecture is the product. The interface is how you use it.
Eight things we do, all of them Odoo. Most engagements start with scoping and end with a support agreement, and everything in between depends on what the business already has — and on what your sector is audited against.
Discovery & scoping
Four stages before anyone configures anything: documentation you complete, user stories per role, working sessions in person or on Teams, and a visit to watch the process actually happen.
Priced by the size of the operation rather than a flat fee, because a corner shop and a fifty-person manufacturer are not the same proposition. The bands are published.
You leave with a written architecture, a module and licence plan, a migration assessment, the full implementation timeline and a fixed price. It is yours to take elsewhere if you want to.
Scoping also covers the standards your customers hold you to. What that means by sector
Odoo implementation
Sales, purchasing, inventory, manufacturing, accounting, projects, field service, point of sale. Configured around your process rather than the demo script, with the apps you don't need left switched off.
Migration from legacy systems
Off spreadsheets, off ageing accounting packages, off the three tools that don't talk to each other. We run the old system alongside the new one until the numbers agree, then switch.
Nobody is asked to stop trading for a weekend. How a migration runs
Data migration
Customers, suppliers, products, stock positions, open orders and ledger history moved across, deduplicated and reconciled. Opening balances are signed off by your accountant before go-live, not after.
Custom module development
Where standard Odoo stops and your business carries on. Written as proper modules against the framework, so a version upgrade is a test run rather than a rebuild.
Expect to need some. Odoo covers most of an operation out of the box; the custom work is there to fill the gaps where your process and the standard product part company, and most operations of any complexity have a few.
Third-party integrations
Payment providers, couriers, marketplaces, EDI, bank feeds and the tools you are keeping. Built with retries and an audit trail, so a failed sync is visible instead of silent.
Hosting & upgrades
Odoo.sh, on-premise or your own cloud. Backups you can restore from, a staging copy that matches production, and annual version upgrades tested there first.
Ongoing support
Named response times and the people who built the system on the other end of them. No first-line script, no ticket that gets passed to someone who has never seen your configuration.
Four stages, and none of them is a demo.
Most implementations fail on things nobody wrote down. So we gather the same operation four different ways and pay attention to where the accounts disagree.
Documentation
A structured questionnaire goes out before we take up any of your time. Completed by the people who do the work, not the person who owns the process on paper. Writing it down is usually the first time a business has had to articulate its own process.
User stories
Role by role, in plain language: what each person needs to do, what they need to know, and what currently stops them. These become the test the finished system is measured against — if a story does not work, the build is not done.
Working sessions
In person or on Teams, whichever suits your week. This is where the awkward questions get asked — the exceptions, the customer nobody wants to lose, the step that only happens in August. Recorded and written up, so nothing depends on somebody's memory of a call.
The verification visit
We come and watch the work happen. Where paper gets picked up, where someone quietly opens a spreadsheet, where the documented process and the real one part company. That gap is the most valuable thing discovery produces.
Discovery ends with a written architecture, a module and licence plan, the full implementation timeline and a fixed price for the build. Yours to take elsewhere if you want to.
Odoo does most of it out of the box. Custom work fills the gaps.
Odoo is a strong standard product. Sales, accounting, stock, projects, helpdesk and a hundred other apps arrive configured and working, and for most of an operation that is what gets deployed. It also makes assumptions about how a company sells, schedules, prices and reports, and where your process disagrees with those assumptions the standard product will not bend on its own.
That is where custom development comes in: not to rebuild Odoo, but to fill the specific gaps between the standard product and how you actually trade. A large proportion of the operations we scope have some, and anyone promising a pure configuration project has usually not looked closely enough. The honest question is not whether you will need code. It is how much, and whether it is written to last.
Hosting decides how much of that is possible. Odoo Online, the subscription cloud, runs standard apps well and costs least, but cannot run custom modules at all. If scoping finds gaps that need code, the system belongs on Odoo.sh or a server we manage. We will tell you which before you commit to either.
Bend your business to the software
The cheap route is to tell you your process is wrong and hand over the standard product. Sometimes that is true and we will say so. Usually the process exists because trading taught you something.
Write code for the sake of it
Every hour of custom development is an hour somebody maintains for a decade. Where configuration genuinely reaches, configuration wins, and we will tell you when it does.
Write it to upgrade
Proper modules against the framework, not edits to core. That is the difference between an annual version upgrade being a test run and being a rebuild you pay for twice.
Find the edges in scoping
Two weeks is mostly spent locating exactly where your process and the standard product part company, so the custom work is a known quantity before you commit to a price.