Muhammad Gharis Javed
Backend Engineer — Odoo · n8n · Claude API · Python . AI
New to Contra
Muhammad Gharis is ready for their next project!
Opening a few backend automation audit slots this week.
Best fit if you are stuck with:
• slow Odoo workflows
• broken API integrations
• duplicate n8n records
• PostgreSQL performance issues
• WhatsApp automation problems
• AI output that is unsafe for ERP/database use
I’ll review the issue and provide a clear technical fix plan.
Stack: Odoo, Python, PostgreSQL, n8n, FastAPI, Docker, WhatsApp API, Claude/OpenAI/Groq.
0
11
Built an Odoo 19 + AI + WhatsApp + n8n Automation Stack Using Open-Source Tools
I just shipped omni-odoo-stack — a portfolio-grade ERP automation project built around Odoo 19 Community, n8n, WhatsApp Cloud API, Groq/Llama 3, FastAPI, PostgreSQL, Docker Compose, and Nginx.
The goal was to demonstrate how a modern business can connect ERP, workflow automation, WhatsApp communication, and AI-assisted processing using open-source or free-tier friendly components.
What’s inside:
4 custom Odoo modules
— omni_crm: AI-scored leads, WhatsApp contact flow, and public REST API
— omni_whatsapp: Meta webhook integration with inbound/outbound message history
— omni_ai: LLM request logging, token tracking, and hourly cron processing
— omni_automation: Automation event tracking, failure logs, and dashboard views
3 n8n workflow automations
— WhatsApp lead intake → AI analysis → Odoo CRM lead → WhatsApp reply
— Invoice payload → AI extraction → Odoo vendor bill → confirmation
— HR onboarding form → Odoo employee record → AI welcome message → WhatsApp notification
FastAPI AI middleware
The AI layer is separated from Odoo and uses Pydantic v2 validation to keep LLM responses structured before they reach ERP fields.
That separation matters.
Instead of putting prompts and model logic directly inside Odoo, the middleware acts as a safety boundary between business data and AI models. This makes the system easier to maintain, test, replace, and scale.
The project also includes:
— Docker Compose orchestration
— PostgreSQL 16
— Nginx routing for Odoo, n8n, and FastAPI
— Environment-based configuration
— Sample n8n workflow exports
— Documentation for setup, architecture, APIs, and deployment path
— OCI Always Free deployment direction
This is not just a simple demo. It is designed as a production-style architecture pattern for Odoo partners, SaaS teams, and agencies that need backend automation, AI middleware, WhatsApp workflows, and ERP integrations.
GitHub: https://github.com/gharisj3/omni-odoo-stack
(https://github.com/gharisj3/omni-odoo-stack)LinkedIn: https://www.linkedin.com/in/muhammad-gharis-javed-318266202/
I’m open to remote contracts involving Odoo backend development, n8n automation, FastAPI middleware, PostgreSQL optimization, WhatsApp automation, and Oracle/Odoo integrations.
DM me or reach out at gharis@omni-academy.com (mailto:gharis@omni-academy.com)
0
12
Built a Python-based static analysis engine that
scans Odoo 14/15/16 custom module codebases and
generates a structured migration report before
a single line of upgrade code is written.
The problem it solves:
Odoo version migrations fail at the module layer,
not the database layer. The breaking changes between
v14 and v17 are silent — modules install without
errors but produce wrong data at runtime because
deprecated API patterns execute without raising
exceptions. Engineers discover these failures in
production, not during migration planning.
This engine finds them before you start.
What it scans:
→ Deprecated API usage: detects v14/v15/v16 ORM
patterns that break silently in v17 — including
renamed methods, removed parameters, and changed
return types on core model methods
→ Broken XML inheritance: flags xpath expressions
targeting views that were restructured or renamed
in the target version — the most common source
of invisible UI breakage post-migration
→ Security CSV issues: validates ir.model.access.csv
structure, detects missing columns, wrong model
references, and group ID mismatches against the
target version's model registry
→ Renamed fields: cross-references custom field
usage against Odoo's official field rename manifest
for each version jump — flags every reference
that will produce a KeyError at runtime
→ Raw SQL risk: detects hardcoded table names in
env.cr (http://env.cr).execute() calls that may have changed
between versions
→ Compute field patterns: flags deprecated
@api.depends usage and missing store= declarations
that behave differently in v17+
Output format:
Structured JSON and Markdown report with:
Critical issues (will break on install)
Warning issues (will break at runtime)
Advisory issues (technical debt to address)
Per-file breakdown with line numbers
Estimated remediation effort per issue category
Compatible: Odoo v14→v17, v15→v17,
v16→v17, v14→v18, v15→v18, v16→v18
Stack: Python · AST module ·
lxml · pathlib · argparse
Open source → https://github.com/gharisj3/odoo-migration-checklist-engine
0
33
Built a lightweight but production-grade AI resume
screening engine — the core intelligence layer
extracted from OmniATS, open-sourced without any
proprietary multi-tenancy or billing code.
The problem it solves:
Manual resume screening is the biggest bottleneck
in any hiring pipeline. A recruiter spending
6 minutes per resume across 200 applicants is
20 hours of cognitive work before a single
interview is scheduled. This engine does it in
seconds with structured, explainable output.
How it works:
→ Takes two inputs: a job description (text) and
a candidate resume (PDF)
→ Extracts structured data from the resume using
Claude API — skills, experience, education,
and key achievements as typed fields
→ Scores the candidate against the job description
on a 0–100 match scale with field-level reasoning
→ Returns a Pydantic-validated output object —
candidate name, match score, extracted skills,
experience summary, and recommended action
→ Auto-correcting feedback loop: if Claude returns
malformed JSON, the validation error is injected
back automatically for self-correction
→ Zero frontend — pure Python CLI and API,
designed to be embedded into any existing
hiring workflow or ATS backend
What makes this production-safe:
Every output is schema-enforced via Pydantic v2.
The LLM cannot return an unstructured response
that breaks downstream logic. The scoring is
deterministic in structure even when the reasoning
varies — you always get a float, a list, and a
string. Never a surprise.
Stack: Python · Anthropic Claude API ·
Pydantic v2 · PyMuPDF · Flask
Open source → https://github.com/gharisj3/llm-resume-screener
0
41
Built a production-grade Odoo batch import toolkit
that bypasses standard ORM overhead for high-volume
data operations.
The problem: Odoo's standard ORM create() processes
records one at a time. At 10,000+ records, this
causes PostgreSQL table lock contention, memory
spikes, and import times measured in hours instead
of seconds.
The solution:
→ Abstract Python mixin (BatchImportMixin) that any
Odoo model can inherit — define your table, columns,
and row mapping, call batch_import(), done
→ Raw parameterized PostgreSQL INSERT with RETURNING
id clause — zero f-string SQL, zero injection risk
→ Chunked processing in configurable batch sizes
(default 500 records per chunk) — safe under any
server memory profile
→ Full audit trail via batch_import_audit table —
every import logged with record count, duration,
company ID, user ID, and status even on failure
→ Multi-company isolation enforced at the mixin level
— company_id injected automatically per Odoo session
→ EXPLAIN ANALYZE benchmark script included — see
exactly how much faster raw PG is vs ORM on your
own data
Benchmark results:
Standard ORM create(): 847 records/sec
Raw PostgreSQL batch INSERT: 48,000 records/sec
Performance gain: 56x faster
Compatible with Odoo v17, v18, and v19.
Stack: Python · Odoo ORM · PostgreSQL ·
psycopg2 · SQL
Open source → https://github.com/gharisj3/odoo-batch-import-toolkit
0
39
Built a production-ready n8n workflow library for self-hosted instances — covering the automation patterns most engineers have to rebuild from scratch on every project.
0
69
Built a production-grade Python middleware service that
wraps the Anthropic Claude API with enterprise reliability
standards.
What's under the hood:
→ SSE streaming via Flask with real-time token delivery
→ Pydantic v2 schema validation on every structured output
→ Auto-correcting feedback loop — validation errors
injected back to Claude for self-correction
→ Exponential backoff retry via Tenacity for rate limits
→ MySQL token usage logger tracking tokens, cost, latency
→ X-API-Key authentication on all endpoints
The result is an LLM integration that behaves like
infrastructure — not a prototype.
Stack: Python · Flask · Anthropic SDK · Pydantic ·
MySQL · DBUtils · Tenacity
Open source → github.com/muhammadgharisjaved/anthropic-flask-middleware
0
66