SEBASTIAN
Work File

Odoo ERP Commerce Integration

Built and tuned the Odoo ERP integration across the surfaces that break without it: PDP, checkout, appointments, payments, homepage. The plumbing that connects online commerce to physical operations.

Type:
Transformation
Period:
2018-2022
Company:
Ben & Frank
Role:
Senior Software Engineer / Product Tech Lead
Status:
Shipped
Markets:
MX / CL / Bombavista

Context

ERP integration is where the commerce site stops being only a website. At Ben & Frank, product flows like appointments, prescriptions, checkout, and at-home try-on all depend on what happens in Odoo: inventory, scheduling, prescription records, fulfillment. When the connection between online and operational systems is unstable, both customer experience and back-office reliability suffer at the same time.

This work spanned two roles: first as a Senior Software Engineer building the integration, then as Product Tech Lead tuning and expanding it.

Problem

  • The ERP integration had performance gaps across key surfaces. PDP data was slow to load, appointment flows had reliability issues, and checkout depended on sync patterns that weren't designed for the load they were handling.
  • Engineering decisions about ERP behavior were being made without product context, and product decisions about features were being made without understanding ERP constraints. The two sides weren't talking.
  • Product, design, and engineering each had different mental models of how the systems connected. This showed up in every sprint as delayed decisions and rework.

Approach

Worked across both engineering execution and product-tech leadership. Built and optimized the integration, and also changed how the squad understood ERP constraints, treating them as product constraints, not backend implementation details that someone else handles.

Decisions

  • Prioritize the integration surfaces that are customer-visible and operationally critical: PDP availability, appointments, checkout, payments, homepage.
  • Document ERP behavior as part of the product spec, not buried in backend docs that designers and PMs never read.
  • Use squad rituals to keep product and engineering working from the same understanding of system limits, not discovering them at QA.

Impact

  • Front-office and back-office operations working from a single source of operational truth.
  • Improved reliability and performance across the commerce surfaces that depend on ERP data.
  • A shared product-engineering model for how ERP constraints translate into design and delivery decisions. This reduced rework on subsequent initiatives.