Technology
An app that only looks good is a prototype. The Flutter apps on this page read live catalog data from an ERP, take recurring payments and serve suppliers in the field, because we build the backend they talk to as well.
Reviewed by Atul Makwana, CEO & Co-Founder, Heliconia Solutions · Odoo 16 Functional Certification · Odoo Partner · Updated
Businesses that run on what we built
The short answer
Flutter fits when you need one codebase producing a genuinely native-feeling app on iOS and Android, with a consistent interface you control completely. It suits catalog, portal, field and transactional apps backed by an API. It is the wrong choice when you need deep platform-specific integration on one OS only, or when a responsive web app would have answered the need without an app-store release cycle.
The reason our Flutter work holds up is that we also build what sits behind it. Ramdev Kangan’s catalog comes from Odoo over GraphQL. WaveContact’s subscriptions are Odoo and Stripe. PayRemit’s app is part of a platform our Odoo and Next.js engineers work on at the same time.
That matters because most app problems aren't app problems. They're API shape, data volume, offline behaviour and release process.
What we deliver
Each item comes from an app that is in production, with the project named.
Ramdev Kangan’s suppliers and customers browse a product catalog managed once in Odoo, delivered to a Flutter app over GraphQL with search and filtering built for the way they actually look for products.
WaveContact runs subscription plans and secure recurring payments through Stripe, with the Odoo backend holding orders, memberships and the store behind both the web and Flutter clients.
Product imagery served from Cloudflare R2 with synchronisation from Odoo, so a catalog with thousands of images opens quickly on a phone on mobile data.
PayRemit is a live financial platform where our Flutter developers ship payment, agent and wallet features alongside the Odoo and Next.js team, without stopping live transactions.
Push through Firebase Cloud Messaging, deep links into the right screen, and the notification permissions handled the way each store now requires.
Build pipelines, signing, store listings, staged rollouts and the review cycle handled as part of delivery, because "done" means available to users, not merged.
The pattern
The app is a client. The rules, the catalog and the money stay in the system of record, reachable over an API designed for a phone rather than for a desktop browser.
Customers and members
Consumers browsing, subscribing and paying from their own devices.
Suppliers and field staff
People using the app as a work tool, often on poor connections.
The web client
A Next.js site or portal sharing the same APIs and the same accounts.
Flutter application
One Dart codebase for iOS and Android, with state management, caching and error handling chosen for the data volumes the screens actually carry.
API layer
GraphQL or REST shaped for mobile: the fields a screen needs in one round trip, paginated, with authentication and token refresh designed in.
Media and delivery
Images and files on S3-compatible object storage with renditions, so the phone downloads the size it needs rather than the original.
System of record
Odoo or the platform backend: products, stock, orders, subscriptions and payments. The app never becomes the place a business rule lives.
Honest positions
We build in Flutter and React Native, and we will tell you when the answer is neither.
| Your situation | What we would recommend | Why |
|---|---|---|
| One product, both platforms, a controlled interface | Flutter | One codebase, consistent rendering, and a fast path from design to shipped screens |
| A React and Next.js team that will maintain the app | React Native | Shared language and mental model with the web team matters more than the framework debate |
| Heavy platform-specific features on one OS | Native | When the differentiator is a platform capability, a cross-platform layer is a tax rather than a saving |
| Occasional access to information staff already see on the web | A responsive web app, no store release | An app carries store review, updates and two build pipelines. Only pay that when the app earns it |
| Truly offline field work | Flutter or native, with offline designed first | Offline is an architecture, not a feature you add later. It changes the data model and the sync rules |
Freiburger Bund runs React Native rather than Flutter, because that product shares a codebase and a team with its Next.js web app. Same principle, different answer.
How we work
Evidence
Three apps, three different jobs: a supplier catalog, a subscription product and a financial platform.
| Project | Industry | Odoo | Key capabilities | Technology |
|---|---|---|---|---|
| Ramdev Kangan | Jewellery manufacturing | Odoo | Headless Odoo API · GraphQL API Extensions · Flutter Mobile Application · Product Catalog Management | Odoo · Python · GraphQL · Flutter · Cloudflare R2 |
| WaveContact | SaaS: digital business cards | Odoo | Digital Business Card Management · Contact Management · Profile Management · Subscription Management | Odoo · Python · PostgreSQL · GraphQL · Flutter |
| PayRemit | FinTech: digital payments & remittance | Odoo | Agent Management · Employer Management · Commission Management · Payment History Reports | Odoo · Python · PostgreSQL · Next.js · Flutter |
Read the projects
A catalog app served by headless Odoo over GraphQL, and a subscription product with Stripe billing behind web and mobile clients.
Jewellery manufacturing
A bangle and fashion-jewellery manufacturer’s product catalog managed in Odoo and delivered to a cross-platform Flutter app over GraphQL, with media on Cloudflare R2 and production monitoring.
SaaS: digital business cards
Digital profile and contact-sharing platform where Odoo runs subscriptions, orders and the store behind a web frontend and a Flutter mobile app, with Stripe recurring payments, Google integrations and vCard export.
Two ways to work with us
This page is about delivering an app. If you need Flutter capacity inside your own team, working in your repository and your release process, that is a different engagement.
What clients say
Heliconia transformed our business with Odoo. They implemented a dynamic website with e-commerce capabilities, enhancing our online presence significantly.
Sandesh ThummarBusiness Owner, Ladder LogixHeliconia provided a unique canteen solution, saving us valuable ordering time. Their innovative approach has been invaluable to our operations.
Pradeep LakhaniBusiness Owner, Avasar AgencyQuestions
Yes, and it is the architecture we build most often. Odoo exposes products, stock, orders, customers and subscriptions over GraphQL or REST, and the Flutter app is a client of that API.
Ramdev Kangan’s catalog app works exactly this way, with the product data managed once in Odoo and media served from object storage.
Usually a team question rather than a technology one. Flutter gives one Dart codebase with consistent rendering and a quick path from design to screens. React Native shares a language and often components with a React web team.
We build both: Ramdev Kangan, WaveContact and PayRemit are Flutter, and Freiburger Bund is React Native with Expo, because it shares a stack with its Next.js portal.
Yes. WaveContact runs subscription plans with Stripe recurring payments behind both its web frontend and its Flutter app. Payment flows need care with store rules on digital goods, and we design that in rather than discovering it at review.
Yes: build pipelines, signing, store listings, privacy declarations, review responses and staged rollouts. An app that is merged but not released is not delivered, so we treat the store as part of the work.
It can, and it is an architecture decision rather than a feature. Offline changes the data model, the sync rules and the conflict handling, so it has to be designed from the start. Tell us how often your users are genuinely out of coverage and we will size it honestly.
Yes, and most of our mobile work is ongoing rather than one-off. WaveContact has shipped releases over 12 to 15 months, Ramdev Kangan over 8+ months and counting, and PayRemit is continuous delivery on a live platform.
Next step
The screens are the visible part. Send us the system behind them, who uses the app and where, and we will propose an architecture, an API shape and a release plan.