Most support contracts promise priority without saying priority over what. Ours are defined by two numbers: how quickly we answer, and how much work is included. Both are measurable, and both are things you can hold us to.
The business problem
Something in Odoo stops working and nobody owns it. The original developer is unreachable, the partner is between contracts, and the finance team is closing the month by hand.
What is needed is not a bigger contract. It is a named response time, and somebody who has read the code before the day it breaks.
What we build
Our modules or another vendor, set up against your data and your rules rather than a demo database.
A stated response time during business hours, and an honest estimate the first time we answer.
Your database, on the next version, before you commit to it.
Included configuration hours, so a small change does not need a purchase order.
Reference architecture
Boring on purpose: one API surface, one source of truth per concept, integrations at the edge, and an audit trail from day one. Diagrams are produced per project and included in the handover pack.
Related
FAQ
No. We support Odoo instances we did not build, and modules we did not write. We will say so plainly if something is beyond what we can safely maintain.
They are the defining feature of the tier, so they are stated in the agreement rather than described. Ask and we will send the current tiers before you commit to anything.
Only with your permission, only for the ticket in hand, and access is removed when it is closed.
A short paid discovery: we map the process, agree the architecture and produce a scoped plan you own regardless of who builds it.
Fixed for discovery and clearly bounded phases. Time and materials for ongoing product development, with a monthly cap.
You do, from the first commit, in your own repository.