Odoo services · Odoo Development Services
Custom Odoo modules, built to Odoo conventions.
When configuration genuinely runs out, the module that replaces it should look like something the Odoo core team would recognise: standard ORM patterns, proper access rules, and tests that run in CI.
—— Where it hurts
The problems this work actually solves.
Most Odoo problems are configuration problems, and we say so when they are. The situations below are different — this is where custom code is genuinely the right answer, and where badly written code does the most lasting damage.
The workflow that almost fits
Standard Odoo covers most of the process, but one step simply does not exist — a Thai tax document, a costing rule, an approval chain your auditors require. Staff bridge the gap with spreadsheets, and the data quietly splits into two versions of the truth.
How we handle itWe specify that one step precisely and build it as a small inheriting module. The standard flow stays standard; only the gap gets code.
A customisation that blocks every upgrade
An earlier developer edited core files, or copied entire modules to change one function. Every version upgrade now breaks something, and each hotfix plants the next failure.
How we handle itWe rebuild the same behaviour as clean inherited extensions that leave core untouched. The next upgrade then works with your modules instead of fighting them.
Screens that slowed down after go-live
List views take seconds to open and confirming an invoice hangs. The usual culprits are custom compute fields and loops that query the database one record at a time — and they get worse every month as data grows.
How we handle itWe profile the real queries first, then rework the code to read in batches and store what Odoo allows to be stored. No guessing, no blanket rewrites.
Code only one person understood
The developer who built your modules has moved on. Nobody dares change anything, so every small request becomes a risk discussion instead of a task.
How we handle itWe document as we read, wrap the current behaviour in tests first, and only then start changing code. Safety comes before speed.
Requirements that moved mid-build
The business changed while the project ran, and the developer either kept building to the old brief or improvised without records. Months later, nobody can say which behaviour is intentional and which is accident.
How we handle itWe work to a fixed written scope per phase. When a requirement changes, the change is specified and re-quoted in writing, so the spec always describes what actually ships.
—— Learn from other projects
Mistakes we see, and how to avoid them.
Paying developers to rebuild a checkbox
Odoo's settings and standard flows cover far more than most buyers assume, and a surprising share of "custom requirements" are already in the product. Development bought here is money spent twice, plus maintenance forever after. We check configuration and standard modules before quoting anything, and tell you when the answer is a setting rather than code.
Editing Odoo's core source
It is the fastest way to change behaviour and the surest way to weld yourself to one version forever. Once core is patched, every update becomes a merge project and every bug has two possible homes. We change behaviour only through Odoo's inheritance mechanisms; core stays exactly as Odoo shipped it.
Rebuilding what OCA already maintains
The Odoo Community Association publishes thousands of peer-reviewed modules covering common gaps — report formats, workflow variants, technical utilities. Paying to rebuild one from scratch buys you the maintenance burden the community was already carrying. We search OCA before writing anything, and extend an existing module when a real fit exists.
Deploying straight to production
Without a staging database, the first person to test new code is your accounting team, on live data, during working hours. When something breaks, there is no clean way back. We develop against a copy of your database, release through staging, and deploy to production with a tested rollback plan.
One giant module for everything
A single module that touches sales, stock and accounting at once cannot be tested in isolation, shipped in phases, or removed when one part turns out wrong. It turns every small change into a full-system release. We split work into small modules with one responsibility each, so pieces can ship, evolve and retire independently.
—— Ways to engage
Three ways to start with us.
Scoped module build
One defined piece of functionality, specified in writing, quoted at a fixed price, and delivered to your repository. The right shape when you know what is missing and want the cost known before work starts.
- Specification with acceptance criteria, signed before the first line of code
- Fixed price per module — spec changes are re-quoted, never absorbed
- Delivered with tests and a README, in your repository from the first commit
Development retainer
For companies already running Odoo that need a steady stream of small changes — new reports, field logic, workflow adjustments — without contracting each one separately.
- A prioritised backlog you review and reorder with us every month
- The same consultant handles every request, so context never resets
- Every change ships through staging with tests, however small it is
Customisation rescue
For a stalled build or inherited code nobody can maintain. We establish what actually exists before anyone writes anything new.
- A written audit of every custom module: keep, repair or replace
- An honest repair-versus-rewrite costing — sometimes the rewrite is cheaper
- Stabilise with tests before any new feature is added
Your implementation partner
A partner, not a licence reseller.
We are not chasing licence volume — we design, build and stay accountable for systems that companies run their operations on. The consultant who scopes your project stays through go-live and the support that follows, and everything we commit to is written into a fixed scope per phase.
—— What done looks like
Outcomes you can verify yourself.
Code your team can read
Standard Odoo patterns, a README that explains why each module exists, and names that match the business language. Verify it by handing the repository to any Odoo developer we have never met.
Acceptance you can watch
At handover, each acceptance criterion from the spec is walked through on your data, one by one. Sign-off happens because you saw it work, not because a report said so.
Releases without breath-holding
The test suite runs before every release, and your team can run it too. When an Odoo update lands, breakage shows up in the test output — not in a call from accounting.
An upgrade path that stays open
Because everything extends core through inheritance, moving to the next Odoo version is a bounded porting job you can price, not an excavation. The specification doubles as the porting checklist.
—— How we work
What the engagement looks like.
Written specification
Behaviour, edge cases and acceptance criteria agreed before a line is written. Ambiguity is cheaper to fix here than in code.
Build with tests
Every module ships with automated tests. They are what let the next person change it without fear.
Handover
Source, tests and a README in your repository. Your team can maintain it without calling us.
—— Why us
What you get that you would not elsewhere.
Odoo-native patterns
Standard ORM, proper record rules, correct multi-company handling. Any Odoo developer can pick it up.
Tests, not promises
Acceptance criteria become executable tests, so "done" is demonstrable rather than asserted.
No vendor lock-in
Code lives in your repository under your account from the first commit.
Not sure where to start? A short call sorts it.
Talk to an Odoo specialist ➜—— Why us
What working with us is actually like.
An Official Odoo Partner writes the code
We are an Official Odoo Partner under the India programme, and our modules follow the conventions Odoo expects of partner work. That is not a badge for the footer — it is why any Odoo developer after us can maintain what we build.
One consultant from spec to go-live
The person who writes your specification is the person who sees it through build, testing and go-live. No relay from salesperson to analyst to developer, and no requirements lost at each baton pass.
Fixed written scope, phase by phase
You see the price and the acceptance criteria before work starts. When the spec changes, we re-quote in writing rather than absorbing the cost quietly and recovering it somewhere else in the project.
Thai and English, both native
Requirements gathered in Thai do not get translated twice before reaching the developer. Specs, READMEs and handover sessions come in the language your team actually reads.
Three offices, your working hours
Bangkok, New York and Delhi NCR mean development questions get answered inside your business day, not the morning after. Reviews and releases do not wait for a single office to wake up.
We argue against unnecessary code
Every line we write is a line you maintain forever, so our first job is proving it is needed at all. If a configuration change or an existing OCA module covers the requirement, the quote says so — even when that makes the quote smaller.
No licence agenda behind the advice
Odoo Community costs nothing in licence fees, and we say so plainly. Where Enterprise genuinely earns its cost, Odoo bills you directly and we never mark it up — so nothing we recommend is bent by a commission.
Built so you can replace us
Code, tests and documentation live in your repository from the first commit, and the handover assumes we might not be back. We would rather win the next phase on the quality of the last one than on the cost of leaving.
—— Partner tiers, explained
What an Odoo partner tier does and does not tell you.
Odoo ranks partners by certifications held and licence volume sold. A tier signals commitment to the programme — it does not tell you who will actually staff your project. Ask that question of any partner, including us.
Learning Partner
New to the programme, building their first certified consultants and reference projects. Not a red flag — everyone starts here — but ask for hands-on proof.
Official Partner
Certified consultants and active delivery. This is where we sit, enrolled through the India programme, delivering from Thailand, the USA and India.
Silver & Gold
Higher tiers earned mainly through licence sales volume and headcount of certified staff. A strong signal of scale — not automatically of fit for your project.
—— Who this is for
Built for your size, not resized for it.
Growing companies (5–100 people)
For companies of 5 to 100 people, custom development should be a scalpel, not a platform: one or two small modules that close a real gap, at a price known before work starts.
- Standard Odoo covers most of your operation, but one process — a document format, an approval step, a pricing rule — has no clean fit.
- You have no in-house developer, so the code must survive without one — tests, a README and standard patterns are not optional.
- A fixed price per module matters, because an open-ended day rate is a risk your budget cannot carry.
- You inherited a freelancer's customisation and want it stabilised before it fails at the worst possible moment.
Mid-market (100–500 people)
Between 100 and 500 people there is usually an internal IT team; our job is to add Odoo-specific depth and keep a growing codebase coherent.
- Your IT team owns Odoo but needs extra Odoo-specific capacity for a defined module or a fixed deadline.
- Multi-company, multi-currency or multi-country structures need record rules and data models done correctly the first time.
- Several people commit to the same codebase, and you want external review that pulls everyone onto one standard.
- Accumulated customisations are blocking a version upgrade, and each one needs an honest keep, rebuild or drop decision.
—— Risks
What usually goes wrong — and how we prevent it.
Modules without tests
A module without tests breaks silently on the next update. Ours ship with an automated test suite that runs before every release.
Building against a verbal spec
Verbal requirements end in disputes about what was agreed. We build against written, signed specifications with acceptance criteria.
Code held in a vendor repo
Source held hostage means you cannot change vendors. Your repository owns the code from the first commit.
—— Pricing
What this costs.
Fixed price per module against the written specification. Changes to the spec are re-quoted rather than absorbed silently.
From our own engineering team
TechAfterMe Dashboard — AI Dashboard Builder
No-code dashboards for any Odoo model: 12+ chart types, live filters, exports — your data never leaves your server.
$493.11 one-time
View details ➜—— Editions & hosting
Community, Enterprise, and where it runs.
The licence and the hosting are separate decisions, and both are yours — we implement either edition and hand over whichever infrastructure you choose.
$0 licence
Odoo Community
Open source and free to license. Covers sales, purchasing, inventory, invoicing, manufacturing and more. You pay for implementation, not rent.
Per user, billed by Odoo
Odoo Enterprise
Adds studio, advanced accounting and localisations, mobile apps and official support. Billed by Odoo directly — never marked up by us.
Odoo.sh · VPS · on-premise
Your server or the cloud
Odoo.sh, a VPS we manage, or your own hardware. We recommend based on your compliance and budget, then document the choice so it stays portable.
—— The toolkit
What this service usually touches.
—— Related
Explore what else we do.
—— FAQ
Questions teams ask about this service.
Which Odoo versions do you develop for?
Odoo 16 through the current release, Community and Enterprise. For anything older we would usually recommend budgeting the upgrade instead — building new features onto an unsupported version is money spent twice.
Do you publish to the Odoo App Store?
We can, if you want the module distributed. Most client work stays private, which is the default unless you ask otherwise.
How long does a custom module take to build?
A small module — a report layout, an approval step, some field logic — typically takes one to three weeks including specification and testing. Larger builds are split into phases, each with its own scope and price, so you see working software early rather than waiting months for one delivery. The written spec states the timeline before you commit to anything.
Do you build with Odoo Studio or write code?
Code, for anything that needs tests or has to survive upgrades. Studio has its place for quick field additions and view tweaks, but Studio customisations cannot carry automated tests and are awkward to move between databases. Business logic lives in proper modules, in your repository.
Can our in-house developers work alongside yours?
Yes, and it usually works well. We share the repository, review each other's pull requests, and agree conventions at the start so the codebase reads like one author wrote it. A first module built together also becomes a template your team can follow on its own afterwards.
Will a new Odoo version break our custom module?
Major versions change APIs, so every custom module needs a porting pass — that is true whoever builds it, and anyone promising otherwise is selling. Because our modules extend core through standard inheritance and ship with tests, the port is a bounded job we can quote, and the test suite shows exactly what the new version broke.
Do we need an Enterprise licence to run custom modules?
No. Custom modules run on Odoo Community, which costs nothing in licence fees. If your requirement touches Enterprise-only features — Studio, certain localisations, Odoo.sh hosting — we say so up front; Enterprise is billed by Odoo directly and we never mark it up.
Let's find out whether Odoo actually fits your business.
A short call, an honest answer. If it isn't the right system for you, we'll say so.