Available for senior Odoo roles & consulting
Odoo / Python Backend Developer
I close the gap between standard Odoo and how your business actually runs — custom modules, integrations and automation across v13–v19 that survive the next upgrade instead of breaking on it.
About
Every custom line of code is a line someone maintains through the next seven upgrades. I'm as willing to argue a customisation out of scope as into it, and I choose extension points that carry forward on upgrade instead of patches that have to be rewritten each release.
Python, the Odoo ORM and PostgreSQL are where I live. When an instance crawls under real volume, I profile the queries and fix the logic — a bigger server is the expensive way to postpone the problem.
Most ERP pain isn't technical: it's a process that was never written down being forced into software that assumes it was. I start by watching how work actually happens, then make the ERP the single source of truth — no spreadsheets on the side, no data keyed in twice.
Tech stack
What I'm actually deep in, rather than everything I've touched once.
Experience
NEXEVOLVE · Sydney, Australia · Remote
Own the technical direction of every Odoo engagement — architecture, code standards, review and release. Design modules on Odoo 18/19 with OWL frontends, and turn stakeholder requests into scoped, buildable work — including saying no to customisation that standard Odoo already covers.
Ioppolo & Associates · Perth, Australia · Remote
Owned Accounting, Inventory, HRMS and Sales customisation from first requirement call through production support. Replaced recurring manual routines in finance and HR with automated workflows, removing a standing source of reconciliation errors. Integrated third-party APIs and rewrote modules that had grown brittle under production volume.
Nexus Incorporation Pvt. Ltd. · Kathmandu, Nepal
Joined as an intern and left as a senior developer four years later. Built and customised Inventory, Sales and operational workflow modules for live deployments across Odoo v13–v17, and became the person the team routed OWL/XML work, API integrations and version migrations to.
Featured projects
One product anyone can buy and inspect, plus the client work that pays the bills. Where NDAs cover the details, I describe the problem and the approach.
Odoo expertise
Seven consecutive releases, no gaps. I've seen which customisations survive an upgrade and which quietly become someone's problem two years later.
Versioned, documented, upgrade-safe modules instead of core patches.
Inheritance patterns, computed fields, constraints, batch-safe writes.
ACLs, record rules, groups and multi-company access done correctly.
View inheritance and xpath surgery that survives upgrades.
QWeb PDF and Excel reporting matched to what finance actually signs off.
Modern reactive components — including a commercial date picker on the Apps Store.
Controllers, auth, rate-limits and versioned endpoints for external systems.
Payment gateways, third-party APIs, webhooks and scheduled sync jobs.
Query profiling and ORM optimisation for instances that crawl under real volume.
Under the hood
The round trip every click in Odoo takes. Press Run request and watch a real-looking request travel down to PostgreSQL and back, logged live — or click any stage to inspect it.
// click “Run request” to trace a sale-order create through the stack
Code showcase
Three small, real-world patterns — a model, a view inheritance, and an OWL component.
# Batch-safe compute with proper dependencies —
# no per-record queries, no stale cache.
from odoo import api, fields, models
class SaleOrder(models.Model):
_inherit = "sale.order"
margin_pct = fields.Float(
compute="_compute_margin_pct", store=True)
@api.depends("order_line.margin", "amount_untaxed")
def _compute_margin_pct(self):
for order in self:
order.margin_pct = (
order.margin / order.amount_untaxed * 100
if order.amount_untaxed else 0.0)Stored computes with explicit @api.depends keep list views fast — the value is read from the DB, not recalculated per row.
<!-- Extend, never replace: xpath on stable anchors
so the view survives the next upgrade. -->
<record id="view_order_form_margin" model="ir.ui.view">
<field name="inherit_id" ref="sale.view_order_form"/>
<field name="arch" type="xml">
<xpath expr="//field[@name='amount_total']"
position="after">
<field name="margin_pct"
groups="sales_team.group_sale_manager"/>
</xpath>
</field>
</record>Anchoring xpath to a core field name — not layout structure — is what keeps inherited views working across version upgrades.
/** Small, reactive, disposable — OWL the way
the core team writes it. */
import { Component, useState } from "@odoo/owl";
import { registry } from "@web/core/registry";
export class MarginBadge extends Component {
static template = "sale_margin.MarginBadge";
static props = { record: Object };
setup() {
this.state = useState({ expanded: false });
}
get tone() {
return this.props.record.margin_pct >= 25
? "success" : "warning";
}
}
registry.category("fields").add("margin_badge", MarginBadge);Registering through the fields registry means the widget drops into any view with widget="margin_badge" — no core edits.
GitHub
Pulled live from github.com/diablo-stha.
Couldn't reach the GitHub API just now — browse the profile directly.
Services
Five ways this normally starts. If your problem doesn't fit one cleanly, describe it anyway — scoping it correctly is part of the job.
When standard Odoo doesn't match how your business works. I build the missing piece as a proper module — versioned, documented, upgrade-safe — instead of patching core and creating a problem for whoever comes next.
Moving off an older release without losing the customisations you paid for. I've worked every version from v13 to v19, including inherited legacy code by developers who are long gone and left no notes.
Payment gateways, third-party APIs, and data migration out of the legacy system you're still paying for. The goal is always the same: stop people entering the same information twice.
For instances that worked fine at launch and now crawl under real volume. I profile the actual bottleneck and fix the queries or the logic — a bigger server is the expensive way to postpone the problem.
For teams running Odoo seriously without an in-house Odoo developer. Continuous improvement, upgrade planning, and someone who already knows your codebase when something breaks at month-end.
Remote, contract or permanent. I've worked Australian business hours from Kathmandu for three years, so time zones are a solved problem rather than something to negotiate.
Credentials
Formal credentials, for the record. The Odoo depth on this page came from production work, not coursework.
Commercial module under OPL-1 — code a stranger can buy, install and audit, reviewed and accepted by Odoo S.A.
VerifiableIn preparation — the credential that formalises the functional side clients already hire me for.
In progressPatan Multiple Campus, Kathmandu · 2018 – 2023. Completed alongside the first years of full-time production Odoo work.
EducationReferences
Named, attributable, and verifiable on LinkedIn. More available on request.
I highly recommend Bipin Shrestha as an ERP Odoo Developer. During our time at Nexus Incorporation Pvt. Ltd., he demonstrated exceptional skills in Odoo customization and implementation. His problem-solving abilities and professionalism were instrumental in delivering successful projects. Bipin's expertise and collaborative nature make him a valuable asset to any team.
Writing
Technical articles in the works — the lessons that keep coming up in client projects.
The extension points that carry forward — and the patterns that quietly break on every version bump.
Reading the SQL behind recordsets, and the three query patterns behind most "Odoo is slow" tickets.
Review process, licensing, support expectations — what I learned publishing a commercial date picker.
Contact
Hiring, freelance builds or ERP consulting — tell me the process that's costing you time, your Odoo version, and roughly when you need it working. You'll hear back within 24 hours.