Who I am

Hi, I'm Lucas Avila, a Software Engineer based in São Paulo, Brazil. I have over six years of experience building and maintaining production software systems, with deep expertise in Python, PostgreSQL, and backend architecture.

0:00 target: 60–90 s
What I'm looking for

I'm looking for a mid-level remote role where I can bring my backend depth into a modern fullstack environment. I'm not starting from zero — I have six years of production systems, architecture decisions, and real business complexity behind me. What I'm building now is the fullstack breadth to match. I'm async-friendly, comfortable across time zones, and I communicate in English at a professional level.

0:00 target: 60–90 s
Current Stack — Odoo

Throughout most of my career, I've worked with Odoo — an open-source ERP platform built on Python, JavaScript, and PostgreSQL. I've covered versions 14 through 18, and I hold five official Odoo certifications. My day-to-day work involves writing custom modules, building REST API and Webhook integrations, managing database migrations, and leading technical implementations for clients in finance and operations. I work in agile teams using Scrum and Kanban, and I'm comfortable communicating directly with stakeholders.

ERP = complex business software managing accounting, inventory, sales, HR. Think SAP or Oracle, but open source.
0:00 target: 60–90 s
New Stack — Fullstack Project

I'm also actively building a modern fullstack skill set. Right now I'm working on a personal project called Expense Tracker — a fullstack web application I designed and built from scratch. The backend is a FastAPI REST API with SQLAlchemy 2.0 async ORM, Pydantic v2 validation, JWT authentication with MFA support, and Alembic for database migrations. The frontend is built with Next.js 16 App Router, TypeScript, Tailwind CSS, and shadcn/ui. Everything runs in Docker Compose, with automated tests on both sides — pytest + httpx on the backend and Jest + React Testing Library on the frontend.

Good add: "You can see the architecture docs on GitHub — I wrote ADRs for every key design decision."
0:00 target: 60–90 s
Positioning the Odoo Background
Handling pushback on niche experience — practice these responses out loud.
Explaining Odoo without sounding niche

I've spent six years building custom modules and integrations on Odoo, which is a large-scale Python/PostgreSQL application — around 1.5 million lines of code, modular architecture, ORM layer, background job processing, REST and XML-RPC APIs. The work I did wasn't clicking through a UI — it was writing Python, designing database schemas, debugging production performance issues, and integrating with external systems. The domain happened to be ERP, but the engineering problems are the same ones any SaaS company faces: data consistency, API reliability, performance at scale, test coverage. I'm now applying that experience to a more conventional modern stack — FastAPI, Next.js, PostgreSQL — and the fundamentals transfer directly.

Frame it as backend engineering with a specific domain — not as "Odoo experience." The domain is ERP; the skill is Python backend at scale.
0:00 target: 45–60 s
Skills that transfer to a Python/FastAPI role

The skills that transfer directly: Python at production scale — I've debugged performance in 1M+ line codebases, written async code, and worked with PostgreSQL at a level where query plans and indexes matter. ORM depth — Odoo's ORM is more complex than SQLAlchemy in some ways; coming to SQLAlchemy feels like simplification, not a learning curve. API design — I've built and consumed XML-RPC and REST APIs, designed integration contracts, and handled authentication between systems. Debugging instinct — six years of production firefighting means I know how to read logs, isolate regressions, and find the root cause without guessing. Those aren't Odoo skills — they're engineering skills that showed up in an Odoo context.

Be specific. "Python at scale," "ORM depth," "API design" — not generic "problem-solving skills."
0:00 target: 45–60 s
Framing ERP complexity as backend depth

ERP systems are genuinely complex — not in a "we have a lot of features" way, but in a "everything is connected to everything, and a change in one module can cascade into ten others" way. Managing that complexity for six years taught me things about system design that most developers don't encounter until much later: designing for upgrade safety, reasoning about inheritance chains and ORM lifecycle hooks, handling multi-company data isolation, ensuring backward compatibility across module versions. Those are senior backend concerns. The fact that they showed up inside an ERP instead of a SaaS doesn't diminish them — if anything, the constraints were harder.

The "constraints were harder" line reframes the niche as depth, not limitation. Use it when the interviewer implies the work was simpler than SaaS.
0:00 target: 45–60 s
Responding to "we'd prefer SaaS experience"

I understand that concern — and I want to address it directly. The Expense Tracker I'm building exists precisely to demonstrate that the skills transfer. It's a production-quality fullstack app, built with the same stack you're asking about: FastAPI, async SQLAlchemy, PostgreSQL, Next.js, TypeScript, Docker, CI/CD. I wrote the auth from scratch — JWT with refresh tokens and MFA. I designed the database schema with migrations, indexes, and performance in mind. I built a rate limiter with slowapi and Redis. This isn't a tutorial project — it's the kind of work I'd do on your team, in the stack you use. I can walk through any part of it in detail if that would be helpful.

Pivot immediately to the Expense Tracker. Offer to walk through it live — most interviewers will take you up on this, and it ends the "niche" conversation.
0:00 target: 45–60 s