Case study
How a Spanish services company runs its projects, hours and teams on Odoo
A Spanish services company today runs purchasing, sales and projects on Odoo, with its teams clocking in from their phones. Unlike a production floor, here the system's axis is projects, billable hours and the teams that run them — with custom developments and CI/CD backing every change.
The starting point
The challenge wasn't running a production line, but the cycle of a services business itself: quoting a project, selling it, running it with a team that splits its time across several clients, and clocking each person's hours without depending on a fixed post. A single Odoo system had to hold purchasing, sales and projects together, with that logic of hours and teams as the throughline.
What was implemented
Purchasing
Purchasing management integrated with sales and projects, in the same system.
Sales
Sales pipeline connected to the projects each closed deal opens.
Projects, hours and teams
The system's axis: projects with each team's hours recorded and tied to the sales and purchasing that back them.
Mobile clock-in
Teams, spread across different clients and locations, clock in from their phones instead of a fixed post.
Custom developments
In-house Odoo customizations to fit the business's real process, instead of forcing the system into a generic mold.
Full CI/CD
Every change to the custom developments goes through a continuous integration and deployment pipeline before reaching production — the same engineering rigor used to build software, applied here to Odoo customizations instead of deploying changes by hand.
The methodology: client-layer modules, zero core changes
Every custom development is always built in the client's customization layer — never by touching Odoo's core. The result is verifiable: version upgrades run clean, and the custom developments get reapplied and keep working after each upgrade. As we put it to this client: your Odoo updates; so do your developments.
In a services business this matters twice as much: the custom developments that back hourly billing and team management can't get stuck on an old Odoo version. The same discipline of client-layer modules we apply in other sectors is what keeps this system current without losing a single development along the way.
And the project keeps its own AI trainer
uKodeIT and uKITAIz are the same company. As part of the implementation, the project is handed over with its own AI model trained as a special trainer: the client's team can ask, at any time, about the specifications and processes of their own project, in natural language. It's always a private AI — trained for this client and deployable on controlled infrastructure, with no dependency on third-party clouds. It's offered as part of the implementation service, not as a uKore feature.
Frequently asked questions
- For confidentiality we don't reveal the client's name: we describe it as a Spanish services company. The technical details of the case — modules, processes, methodology — are real.
- Because the business doesn't manufacture: it sells and runs projects with teams that split their time across clients. The system was built around that cycle, instead of forcing it into a mold designed for a production floor.
- That every change is tested and deployed through an automated pipeline before reaching production, instead of being pushed by hand — the same control used to build software, applied to Odoo customizations.
- A private AI model, trained on this specific project's specifications and processes, queryable in natural language — an implementation service from uKodeIT/uKITAIz, not a feature included in uKore.