When I joined KA Imaging, the business was running on spreadsheets. Orders, inventory, HR, financials — all of it scattered across files that were increasingly hard to maintain, reconcile, and trust. The team knew it wasn’t sustainable. We needed a proper system.
After evaluating a few options, we landed on Odoo — an open source ERP written in Python, with a modular architecture that covers everything from CRM and accounting to manufacturing and project management. The pitch was simple: one platform, deeply customizable, and no need to bolt together a dozen different tools.
We started by hosting a standard Odoo instance on the cloud. For a while, it worked well enough. But as we got deeper into the platform, we hit a wall: our industry required a level of compliance that the out-of-the-box configuration simply couldn’t satisfy. We needed to modify the software itself — not just configure it.
That’s when we made the move to Odoo.sh, Odoo’s own managed hosting platform built on top of GitHub. Odoo.sh gave us a proper development workflow — branches, staging environments, automated builds — without having to manage infrastructure ourselves. More importantly, it gave us the ability to maintain a separate repository for our custom modules, keeping our changes clean and isolated from the upstream Odoo codebase. No monkey-patching, no risk of breaking things on the next update.
Odoo’s architecture is Python all the way down on the backend. Models, business logic, access control, computed fields — everything is defined in Python using Odoo’s ORM. The frontend layer is driven by XML view definitions, which describe how data is rendered in the UI. It’s an unusual combination if you’re coming from a modern JS framework background, but it’s surprisingly powerful once it clicks.
Our customizations ranged from minor tweaks to significant additions:
The compliance work was probably the most demanding. Healthcare and medical imaging carry strict requirements around data integrity and traceability, and translating those requirements into Odoo’s model layer took careful thought. Getting it right was deeply satisfying.
After all of it, my honest take: Odoo is one of the most versatile business platforms I’ve worked with.
For teams that don’t want to write any code, the standard modules cover an impressive range of business operations. For teams willing to get their hands dirty with Python, the sky is mostly the limit. You can extend nearly anything, override views, hook into the ORM lifecycle, and build integrations with external systems — all while benefiting from Odoo’s built-in authentication, permissions, UI framework, and reporting engine.
It’s not without rough edges. The XML-based frontend can feel clunky compared to modern tooling, and the documentation has gaps that push you toward reading source code. But the tradeoff is a remarkably complete foundation that would take years to build from scratch.
Working with Odoo was one of the more rewarding technical experiences of my career so far. It pushed me to think beyond isolated features and consider how data, workflows, and users connect across an entire organization. It also gave me a deep appreciation for well-designed Python — Odoo’s codebase, at its best, is clean and idiomatic.
If your team is drowning in spreadsheets or patching together disconnected tools, Odoo is worth a serious look. And if you’re a developer curious about it — dive in. The Python is approachable, the community is active, and the problems are genuinely interesting.
More from this era coming soon, including the CAD integration story.
]]>I’ve been thinking about why sharing unfinished work feels uncomfortable, and whether that discomfort is worth pushing through.
The problem with waiting until something is “ready” is that ready keeps moving. There’s always another edge case, another refactor, another thing to polish before it’s fit for human eyes.
Building in public forces a different relationship with quality. Not lower standards — different ones. The question shifts from is this perfect? to is this useful or interesting to someone right now?
Feedback earlier. The most valuable feedback comes before you’ve committed to a direction, not after.
Accountability. Saying you’re working on something in public makes you more likely to actually finish it.
A record. Looking back at how something was built is often more interesting than the thing itself.
You will ship things that aren’t good. People will see half-finished ideas. Some things won’t work out and that’ll be visible.
I think that’s fine. Most people are too busy with their own work to care deeply about your incomplete projects.
So I’m going to try it. Writing here, sharing projects before they’re done, thinking out loud. We’ll see how it goes.
]]>