IT services · Mobile App Development
Apps your team will actually open twice.
Most internal apps die because they were built for a demo, not for a warehouse aisle with one bar of signal. We design for the conditions the work actually happens in.
—— Where it hurts
The problems this work actually solves.
Internal mobile apps fail in predictable ways: they assume good signal, free hands and patient users, and a warehouse aisle or a delivery route offers none of those. These are the problems we are most often called in to solve.
Data stuck on paper
The field team writes on paper or sends photos into a chat, and someone in the office re-keys everything into Odoo that evening. Numbers arrive a day late and a share of them arrive wrong. Nobody trusts the stock report, so people walk to the shelf to check.
How we handle itThe app writes directly to the same Odoo records the office reads. The re-keying job, and the errors it produces, stop existing.
Dead zones kill the workflow
Warehouse racking, basements and upcountry delivery routes all have dead zones. An app that needs a live connection shows a spinner at exactly the moment the work happens, and within a week staff quietly go back to paper.
How we handle itWe build offline-first: work is saved on the device, queued, and synced when signal returns, with the conflict rules agreed in writing during scoping.
The team will not open it
The app was designed in a meeting room, so a task that took one motion on paper now takes five taps with gloves on. Usage drops after launch week, and management concludes that mobile does not work here.
How we handle itWe watch the task performed before we design the screen, and we count taps. If the app is slower than paper, the design is wrong and we change it.
A second database to argue with
The previous vendor gave the app its own backend, so stock in the app and stock in Odoo drift apart. Someone now spends hours every week reconciling two systems that were both supposed to be the truth.
How we handle itOdoo is the only backend. The app is a window onto the same records, not a copy of them.
OS updates arrive on their schedule, not yours
Apple and Google ship major OS versions every year and retire old SDKs on fixed deadlines. An app nobody maintains works fine until one September, then starts crashing or gets flagged for removal from the store.
How we handle itWe test against beta OS releases before they reach your staff's phones, and we track store deadlines so an update is planned work, never an emergency.
—— Learn from other projects
Mistakes we see, and how to avoid them.
Treating offline as a feature for later
Retrofitting offline support means rebuilding the data layer, which in practice means rebuilding the app. It is the single most expensive deferral in mobile work. We decide the offline behaviour during scoping and build the sync engine first, not last.
Building both platforms out of habit
Many operations run entirely on company-issued Android scanners, yet the budget quietly doubles to cover an iOS build nobody will install. We start by listing the devices that actually exist in your operation, and we quote for those.
Launching to everyone at once
A big-bang rollout to eighty drivers turns every small design miss into eighty complaints on the same morning, and the app's reputation never recovers. We release to a pilot crew of five to ten, fix what they find, and only then widen.
No plan for the devices themselves
The app is finished, but nobody decided who installs updates on forty shared handhelds, what happens when one is dropped, or how a new hire gets set up. We put device management — enrolment, updates, replacement — into the rollout plan, not into an afterthought.
Ignoring store rules until submission week
Apple in particular rejects apps over sign-in flows, permission wording and missing privacy details, and each rejection costs a review cycle. We design against the store guidelines from the first screen and write the review notes ourselves, so submission is a step, not a gamble.
—— Ways to engage
Three ways to start with us.
Scoped build
One workflow, taken from field study to a released app your team uses daily. Each phase has a written scope and a fixed price before it starts.
- Field study and a written specification you own, whoever builds it
- Offline sync and Odoo integration included from the first build
- Store submission, review responses and phased rollout handled by us
Rescue and take-over
For an app that is stuck mid-build, or was delivered by someone who has since disappeared. We establish what exists before anyone spends more money.
- Code, backend and store-account audit with a written verdict
- Signing keys, listings and source code recovered where they can be
- Repair versus rebuild, priced side by side so you decide with numbers
Release care retainer
A monthly arrangement that keeps a live app alive: OS releases tested, store deadlines met, and a steady lane for small improvements.
- Each annual iOS and Android release tested before your staff meet it
- SDK and store-policy deadlines tracked and handled ahead of time
- A monthly window for the small changes your team keeps asking for
Your implementation partner
A partner, not a licence reseller.
We are not chasing licence volume — we design, build and stay accountable for systems that companies run their operations on. The consultant who scopes your project stays through go-live and the support that follows, and everything we commit to is written into a fixed scope per phase.
—— What done looks like
Outcomes you can verify yourself.
The pilot crew uses it unprompted
Before wide release, five to ten of your people do their real job through the app for real weeks. You can stand in the aisle and watch, which beats any slide we could show you.
One set of numbers
A stock move made in the aisle appears in Odoo as the same record, with no export or reconciliation step in between. You verify it by opening both screens, not by taking our word.
An offline test you run yourself
Acceptance includes putting a device in airplane mode, doing the work, reconnecting and watching it sync. If that test fails, the phase is not done, whatever the invoice says.
A handover that stands alone
Source code sits in your repository, the store accounts and signing keys are in your name, and the build instructions work for a developer who has never met us. Continuing with us stays a choice, not a dependency.
—— How we work
What the engagement looks like.
Field research
We watch the task performed before designing a screen for it. Gloves, glare and dead zones change the design.
Offline first
The app works without signal and reconciles when it returns, because signal is not a guarantee anywhere real.
Store release
We handle App Store and Play Console submission, review responses and phased rollout.
—— Why us
What you get that you would not elsewhere.
Offline is the default
Queue and sync built in, not bolted on after the first warehouse complaint.
One codebase where it fits
React Native when the app is forms and lists; native when it is camera, sensors or heavy scanning.
Odoo as the backend
No second source of truth to reconcile. The app reads and writes the same records your office does.
Not sure where to start? A short call sorts it.
Talk to an Odoo specialist ➜—— Why us
What working with us is actually like.
The person who watched your warehouse designs the screens
The same consultant stays from the first call through go-live. What they saw in your aisle in week one shapes design decisions in month three, with nothing lost in a handoff between departments.
Fixed written scope, phase by phase
App projects are where budgets drift, because one more screen always sounds small. Every phase we run has a written scope and a fixed price before it starts, so a change is a decision you make, not a surprise you receive.
Both ends of the integration are ours
We are an Official Odoo Partner under the India programme, and we build the mobile side too. When the app needs a field or an endpoint changed in Odoo, that is a task for us, not a negotiation between two vendors.
Thai on the floor, English in the codebase
Field research and training happen in the language your team actually speaks — we deliver natively in both Thai and English. UI copy is written for the person holding the scanner, not translated at them.
Three offices, one release calendar
Bangkok, New York and Delhi NCR mean a store review response or a crash report does not wait for one office to wake up. Releases land in your quiet hours, whichever time zone those are in.
Licence arithmetic stays honest
If Odoo Community covers your backend, the licence cost is zero and we say so. If you need Enterprise, Odoo bills you directly and we never mark it up — the app budget buys the app.
You hold the keys from day one
Store accounts are opened in your name, signing keys are yours, and code lands in your repository as we write it. If we ever part ways, you lose a vendor, not an app.
We will talk you out of an app
If a responsive Odoo screen in the phone's browser solves the job, a native build is money spent on pride. We tell you that in the study phase, while walking away is still cheap.
—— Partner tiers, explained
What an Odoo partner tier does and does not tell you.
Odoo ranks partners by certifications held and licence volume sold. A tier signals commitment to the programme — it does not tell you who will actually staff your project. Ask that question of any partner, including us.
Learning Partner
New to the programme, building their first certified consultants and reference projects. Not a red flag — everyone starts here — but ask for hands-on proof.
Official Partner
Certified consultants and active delivery. This is where we sit, enrolled through the India programme, delivering from Thailand, the USA and India.
Silver & Gold
Higher tiers earned mainly through licence sales volume and headcount of certified staff. A strong signal of scale — not automatically of fit for your project.
—— Who this is for
Built for your size, not resized for it.
Growing companies (5–100 people)
For companies of 5 to 100 people, this is usually the first custom app: one workflow that paper is visibly losing.
- Your field or delivery team still reports through phone calls and chat photos.
- One workflow — stock counts, deliveries or sales visits — matters far more than an app that does everything.
- You run or plan to run Odoo Community, so the budget goes into the app rather than licences.
- There is no internal IT team, so stores, devices and updates need to be someone else's job — ours.
Mid-market (100–500 people)
For companies of 100 to 500 people, the questions change: device fleets, multiple sites, and an existing Odoo the app must respect.
- Shared scanners and handhelds need managed enrolment and updates, not an APK link pasted into a group chat.
- Rollout goes site by site, with a pilot branch proving the design before the other warehouses follow.
- Your Odoo already carries customisations, and we read them before designing a single screen.
- Your IT team gets repository access and code review from the first sprint, not a zip file at the end.
—— The toolkit
What this service usually touches.
—— Related
Explore what else we do.
—— FAQ
Questions teams ask about this service.
Native or cross-platform?
We pick per project and explain the trade. Anyone who answers this the same way every time is selling their comfort zone.
Can it scan barcodes?
Yes, including with dedicated Zebra and Honeywell hardware, which is usually faster than a phone camera in a real warehouse.
What does an app like this cost?
It depends on how many workflows and platforms you actually need, which is why we will not quote from one phone call. The field study produces a written, fixed price for each phase, so you see the full number before committing to the build. If the number does not work for you, you keep the study and the specification.
How long before our team is actually using it?
A single-workflow field app typically goes from field study to a pilot crew within a few months, with the dates written into each phase's scope. Store review adds days, not weeks, when it is planned for from the start. We would rather give you a date in writing than a fast answer here.
Does an internal app have to go on the public App Store?
No. Apple and Google both offer managed distribution for company devices, so an internal tool never has to appear in public search. We set up whichever channel fits your fleet and handle its rules, which differ from the public store's.
Our Odoo is heavily customised. Does that break the app?
No, but it changes the order of work: we read your customisations before designing any screen, because the app must respect the same validations and workflows your office users live under. Since the same consultant handles both the Odoo side and the app side, that reading actually happens.
Who owns the code and the store accounts when the project ends?
You do, from the start, not just at the end. Store accounts are registered to your company, signing keys are yours, and code is pushed to your repository as it is written. We ask you for access — never the other way around.
Let's find out whether Odoo actually fits your business.
A short call, an honest answer. If it isn't the right system for you, we'll say so.