NUZM builds mobile applications in Flutter, native Android and cross-platform, and supports them afterwards. For most business apps cross-platform is the right default, because two native codebases means two teams, two release cycles and two versions of the same bug.
When native is genuinely worth two codebases
When the app is the device. Background location running for hours, hardware sensors, Bluetooth peripherals, or performance that a drawn interface cannot match. Delivery riders, field data collection and scanners are the clear cases. A forms-and-lists app for internal staff is not.
What we build
- Flutter: both platforms from one codebase, with the design your own rather than the operating system's default.
- Native Android: Kotlin against the platform directly, for apps that depend on the device itself.
- Cross-platform: a recommendation made against your requirement rather than our preference, with the platform-specific parts isolated where they belong.
- Custom mobile apps - the app, the API behind it and the admin panel as one project rather than three quotes.
- UI and UX design: screens designed against real content and real device sizes, so what is approved can actually be built.
- Maintenance and support - platform and dependency updates on a schedule, before a store deadline forces them.
The part that is usually left out of a quote
An app is a commitment to maintenance, not a delivery. Android and iOS both make breaking changes on a schedule you do not control, and an app left untouched for two years eventually stops being installable at all. Worse, it cannot then be updated one step at a time, because the intermediate versions have gone, so it becomes a rebuild wearing the word update. That ongoing cost belongs in the first conversation.
Tested on the phone your users actually own
Every build is tested on a low-end Android device on a slow connection, because that is what most users in this market hold. An app approved on a fast phone over office broadband tells you nothing about what your customers will experience.
Questions about mobile projects
Who owns the code and the accounts?
You do, on final payment. That includes the source code, the repository, the domain, the hosting account and every third-party account created for the project. Handover is a step in the project, not a favour asked for afterwards.
What happens after the site or app goes live?
Defects found in the first thirty days are fixed at no charge. Beyond that, support is a monthly arrangement covering updates, security patches, backups and a set amount of change work. You are also trained to run the parts you should be running yourself, because paying an agency to publish a blog post is a waste of your money.
How long does a website take to build?
A content-managed site with your branding and real content is usually a matter of weeks. A custom application depends on how many rules it has to encode and how much existing data has to be migrated. The honest answer is that the build is rarely what sets the date: waiting on content, on approvals, and on access to a system somebody else controls accounts for most delays, and all three are on your side rather than ours. We say so at the start so the schedule is realistic rather than optimistic.
Will the website work properly on a phone?
Every build is tested on a low-end Android device on a slow connection, because that is what most visitors in this market are holding. A site approved on a fast laptop over office broadband tells you nothing about what your customers experience. In practice that testing changes the design: it is where oversized images, unreadable type and buttons too small to hit get caught.
Do you need one platform or both?
Tell us who uses the app and where. Often your own analytics answer it, and often the answer saves you a second codebase.