Technologies
Every technology listed here is running in a named production system we built or maintain. Where we haven't shipped something in production, this page says so instead of listing the logo.
How we choose
A stack is a maintenance commitment, usually for longer than the team that picked it. These are the rules we apply before adding anything to a client's system.
We start from what the software has to do and who maintains it afterwards. A framework that suits the problem badly costs more than one that is unfashionable.
PostgreSQL, Python and Linux carry almost everything we run. Novelty belongs at the edges, where replacing it later is cheap.
We choose technologies with a real hiring pool and public documentation, so your system is not hostage to the team that wrote it, including us.
Data has one owner. Front ends, apps and stores read it over an API rather than keeping their own copy and reconciling later.
Frameworks and ERPs move. We budget version upgrades rather than discovering them when a security release forces one.
Sometimes the answer is configuration, an existing product, or leaving a working system alone. That recommendation is part of the job.
In production
The platforms that hold the operational truth: products, stock, orders, money and people.
Our deepest specialisation: implementation, custom modules, migration, integration and support on both editions, from Odoo 9 through 19 in live systems.
The language behind Odoo modules, integrations and services. Nineteen of the twenty projects on this site run Python in production.
The database under every Odoo system we run, tuned, backed up and restored as part of delivery rather than as an afterthought.
In production
What people see, and how it stays fast while talking to a real backend.
React applications with server rendering: portals, storefronts and product interfaces connected to Odoo, Payload CMS and APIs.
Content-first sites that ship almost no JavaScript. This website is built with it, with Payload CMS behind the blog.
Odoo's own front-end framework and template engine, used when the right place for a screen is inside the ERP rather than beside it.
In production
Apps that do real work, usually against the same APIs the web uses.
One Dart codebase for iOS and Android: catalog apps on live ERP data, subscription products and features inside a live financial platform.
The right answer when the mobile app shares a language, components and a team with a React web product.
In production
Where editorial content lives when it should not live in the ERP or the codebase.
TypeScript-native, self-hosted, running inside the Next.js application: drafts, versions, localisation, live preview and media on object storage.
Instant full-text search across large content sets, used where the CMS query layer is not what a search box should hit.
In production
Storefronts and the operational systems behind them.
A custom storefront over GraphQL with Odoo running catalog, stock, orders and customers. Faster than a standard Odoo website and still one source of truth.
Two-way synchronisation of products, customers, orders, inventory and fulfilment, with reconciliation, so the store and the ERP agree.
Content-led stores on WordPress, decoupled where the storefront needs to be faster than the CMS allows.
In production
The contracts between systems, and the machinery that keeps them reliable.
The API layer we most often expose from Odoo for storefronts and mobile apps: one round trip per screen, with the fields that screen needs.
Idempotent handlers, retries with backoff and scheduled catch-up jobs, because integrations fail and should recover without anyone noticing.
Stripe, Cashfree, Razorpay and Paytm EDC terminals wired into the ledger rather than reconciled by hand.
Socket.IO for sub-second chat and presence, Firebase Cloud Messaging for push, WhatsApp where the customer conversation belongs next to the order.
In production
Where the systems run, and how they get there.
Odoo on Ubuntu with managed PostgreSQL, separate development and production environments and a Git-based release path.
Odoo's own platform where managed infrastructure and staging branches are worth more than full control.
Reproducible environments for development and deployment, used on eight of the systems on this site.
Media and documents served from S3-compatible storage with renditions, so apps and pages download the size they need.
Where it runs
Read this the way we would in a technical evaluation: one row per production system, one column per technology, and a link to what the project actually did.
| Project | Odoo | Next.js | Flutter | React Native | Payload CMS | GraphQL | Docker |
|---|---|---|---|---|---|---|---|
| Aria Jewellers | Yes | –No | –No | –No | –No | Yes | Yes |
| Baroda Hi-Tech Alloys | Yes | –No | –No | –No | –No | –No | Yes |
| Freiburger Bund | Yes | Yes | –No | Yes | Yes | –No | Yes |
| Jo Ann's | Yes | –No | –No | –No | –No | –No | Yes |
| LittleQ | Yes | Yes | –No | –No | Yes | Yes | Yes |
| Made It Easy | Yes | –No | –No | –No | –No | –No | Yes |
| PayRemit | Yes | Yes | Yes | –No | –No | –No | –No |
| Ramdev Kangan | Yes | –No | Yes | –No | –No | Yes | –No |
| Spicy Organic | Yes | –No | –No | –No | –No | –No | Yes |
| WaveContact | Yes | –No | Yes | –No | –No | Yes | –No |
| Wild Cloud | Yes | –No | –No | –No | –No | –No | Yes |
Projects whose only entry here is Odoo are left out, because a row of dashes tells you nothing. The full list is on the case studies page, and every stack on this page comes from the project's own record rather than from a capability list.
What we will not claim
A page here means we have run it in production and can answer hard questions about it. These are the ones that do not qualify yet, stated plainly.
We integrate Shopify with Odoo and build headless storefronts on it, and both have their own pages. We do not present ourselves as a general Shopify agency, because theme and app development is not where our production evidence is.
We have not run either in production, so there is no service page. When we publish comparisons against Payload CMS they will say exactly that, and they will be architecture decisions rather than a pitch.
Real production proof exists (the Freiburger Bund iOS and Android apps), but it is one project. A dedicated page follows when there is a second, rather than stretching one engagement into a capability claim.
We build automation and integrations, including with AI services where a client asks for them. We are not positioning as an AI company, and we will not add a page for it until there is production work worth reading about.
Next step
Tell us what the system has to do, who maintains it and what it connects to. We will propose a stack with the reasoning, including the parts we would not build.