Solutions Architect — Odoo, platform engineering, and the tooling in between
19 years in the field · 100+ Odoo projects · Quito, Ecuador

Español · qit360.com · LinkedIn

I build the tooling I wished existed for Odoo.

After 19 years I stopped believing that an ERP project succeeds because of its code. It succeeds because of everything around the code: the infrastructure, the delivery process, and an honest reading of how the business actually works. The best ERP is not the one with the most features — it's the one that best adapts to the way a company already operates.

odoo-forge — a declarative platform for composing Odoo projects: layered manifests, resolved overrides, and pluggable execution backends. Python · Apache-2.0 · PyPI

An Odoo project is normally assembled by hand: a fixed layout of cloned repositories, a hand-maintained addons_path, a bespoke docker-compose.yml, and version pinning that lives in someone's memory. Reproducing a deployment means reproducing a ritual.

odoo-forge models the project as data instead — a project.yaml resolved into a project.lock that can be validated, pinned to exact commits, materialized onto disk, and provisioned against a chosen backend. The domain core stays free of infrastructure: Git, Docker, PostgreSQL, the image registry and CI all sit behind ports, so a new execution surface is a new adapter, never a rewrite.

uv tool install odoo-forge-toolkit
forge --help

First commit 9 July 2026. Published to PyPI 28 July 2026. 39 merged pull requests, one maintainer.

The practices matter more than the stack, so here is what is actually enforced in that repository:

• Every pull request requires a linked open issue — checked in CI, not by convention
• All GitHub Actions pinned to immutable commit SHAs — a moving tag is a supply-chain hole
• CodeQL, Dependabot and automated review on every change
• A portfolio validator runs inside the default pytest gate — the architecture's structural guarantees fail the build, not a review comment
• Releases published through PyPI trusted publishing — no long-lived tokens anywhere

None of this is unusual on a large team. It is unusual on a three-week-old project maintained by one person, and that is the point: the discipline is what makes a small team move like a large one.

I care about the person who arrives after me. In odoo-forge that meant writing, alongside the code:

• Task-oriented recipes — add a layer, override a fork, handle enterprise credentials
• A comparison page against the alternatives, including where they win
• An animated quickstart, because a GIF explains a CLI faster than a paragraph
• A human-readable roadmap separating what works today from what is only planned
• A Spanish translation of that roadmap, so the docs are not a language barrier

Fixes merged into Gentleman-Programming/gentle-ai, a Go CLI I use daily:

• fix(review): keep the native reason on an unclassified post-progress failure
• fix(review): exclude no-op self-loop authority from pre-PR delivery graph

Reading someone else's codebase well enough to fix it is a different skill from writing your own, and it is worth practising in a language you don't work in every day.

Complex upgrades and migrations. Critical version migrations with data integrity and business continuity as hard requirements.

Solution architecture. Implementations designed to survive growth, avoiding technical debt from day one.

Delivery and platform engineering. Turning chaotic, manual development cycles into predictable releases — removing the fear of deploying to production.

Crisis recovery. Diagnosing and rescuing Odoo projects that are stalled or failing in production.

Process before software. One client lived and breathed the Theory of Constraints and needed the ERP to understand bottlenecks, time buffers and flow-based prioritization. Instead of imposing the ERP's default way of working, we redesigned the procurement logic and stock validations so the system protected the operational flow rather than interrupting it. Technology stopped being a barrier and became the engine of how they already thought.

ERP — Odoo · OWL · XML/QWeb Backend — Python 3.11+ · PostgreSQL · hexagonal architecture (ports & adapters) Platform — Docker · AWS · Terraform · GitHub Actions · GHCR · SOPS/age · uv · Linux Also — Go · data modeling and reporting · AI-assisted delivery workflows

• Odoo V19 Functional Certification — Odoo, 2026
• Odoo V16 Functional Certification — Odoo, 2023

Solutions Architect at Grupo Mirgor. Previously COO managing large project portfolios, and independent consultant.

If your Odoo implementation is causing more problems than it solves, I have the experience to turn it around.

qit360.com · LinkedIn