How we work.
Six things that hold true on every engagement, whether it starts as a fresh build or a rescue.
We start with the system you already have
Almost no one comes to us with a blank slate. There’s an Odoo instance someone else configured, spreadsheets doing the work an ERP should be doing, or a migration that stalled halfway. We start with how your operation runs today, not how a reference implementation says it should. The first paid step is usually a short, scoped Discovery: honest about what we find before anyone commits to a larger build. See engagement models →
We make the architecture call, and we write down why
We have opinions, and we’d rather disagree with you early than build the wrong thing politely. One client came to us on Odoo Enterprise; we moved them to Community: an unusual call, and the right one for what they were building. Decisions like that get recorded: what we chose, what we ruled out, and why. A year on, when someone asks why the system works the way it does, the answer is in writing, not in someone’s memory.
We build in version control, against your production reality
Everything we build lives in Git. Changes move through staging into production along a path we can reverse: nothing gets hand-edited on a live system and hoped over. It’s how we run our own systems, and how we run yours. The result is boring in the best way: you always know what changed, when, and how to undo it. For a system your business runs on, boring is the goal.
Your data and access, on your terms
Every engagement starts under an NDA. We work within your security and access policies rather than around them, and we don’t hold data we don’t need. Where your environment has specific requirements (a Data Processing Addendum, a payment-data boundary, a healthcare context) we work to them. The full detail is on our Trust page, written for the people on your side who have to sign off on us.
You talk to the people doing the work
There’s no account-management layer between you and the engineers. We work on whatever your team already uses (Teams, Slack, Google, WhatsApp) and when something breaks, you hear from us in writing, quickly, even when the fix takes longer than the message. The person explaining the problem is the person solving it.
We stay past go-live
Go-live is a milestone, not an exit. Roughly a third of our delivery effort goes to systems that were already live when we reached them: made stable first, then made better. Most of our longer relationships continue under a renewable continuity arrangement, staffed by the same engineers who built the system. The version you launch on is not the version you’re stuck with. See engagement models →
Bring us the hard version.
If your system is mid-migration, quietly broken, or nobody’s sure how it works anymore, that’s the conversation we’re best at. A scoping call is with an engineer, not a salesperson.