Loading
Product line
The artefact is a signed build in two stores, an offline-tolerant data layer behind it, and a release pipeline you can run without us. This page describes what is inside one, not how the project is run.
Mobile product · in the build
Anatomy
Roughly two thirds of the engineering in a mobile app is invisible from the screenshots. These are the parts that decide whether it holds up after the first week.
Tabs or a stack, deep links that resolve from a cold start, and a back gesture that behaves the way each platform expects. Decided first, because retrofitting a navigation model touches every screen.
A device database and an explicit answer to what happens when the network is gone: which actions queue, which are refused outright, and who wins when the same record changed in two places. Written down before the first screen is built.
Sign-in including the platform providers, tokens held in the keychain or keystore rather than in shared preferences, silent refresh, and permission prompts asked at the moment they make sense instead of on first launch.
Signing keys, build numbering, TestFlight and Play internal testing tracks, staged rollout and a crash and performance feed. The part that turns one shipped app into an app you can keep changing.
Why it matters
The same artefact described above, read as outcomes rather than as engineering. Each one follows directly from a decision already explained on this page.
Staff working out of signal range keep entering data instead of losing an hour of work every time the connection drops.
One Flutter codebase covering both stores means a feature ships once rather than twice, at a fraction of running two native teams.
Signing keys and release tracks held in your own accounts mean an update reaches users in days, not a re-negotiation with whoever built the app.
Store-readiness work done before submission — privacy declarations, review notes, correct screenshots — avoids the week a bounced first submission usually costs.
Accessibility built in from the first screen avoids the much larger bill of retrofitting VoiceOver and TalkBack support after the app has already shipped.
Key features
Behaviour of the built thing, not a list of adjectives. Every entry below is something you can check after delivery.
A mobile product is not a website in a frame. It is a signed binary that has to pass two store reviews, survive a train tunnel, keep a session alive across a cold start, and ask for permissions in a way a stranger will grant. What we build is one Flutter codebase where the app is screens and data, or native Swift and Kotlin where it depends on platform depth — and we will say which of the two your idea actually needs before either of us commits to it.
Technology
A stack we actually run in production. Where your team already has a preference and it is a reasonable fit, we work in yours instead of arguing for ours.
Runs on
Before we quote
Each of these is cheap to settle now and expensive to revisit after the first release.
If the workflow is occasional and always online, a well-built mobile web application reaches the same people with no store review and no update lag. An install earns itself when you need the camera, background work, offline use, hardware, or a home-screen presence people return to daily. We will tell you which one we think you are describing, including when the answer costs us the larger project.
Flutter when the app is screens, lists, forms and an API, which is most business apps — one codebase, one team, both stores. Native when the product's value sits in platform depth: continuous background location, Bluetooth peripherals, complex camera work, widgets and live activities, or hardware-backed key storage. Mixing is possible and usually worse than choosing.
This is the question that decides the architecture, not a feature to add later. Read-only caching is straightforward. Accepting writes offline means a queue, an identifier strategy that does not depend on the server, and a stated conflict rule. We specify it in writing before building, because retrofitting it means rewriting the data layer.
Pricing and engagement
There is no fixed price for mobile applications because the scope varies by how much of the product depends on native platform depth and how ambitious the offline story needs to be — here is how the work is actually engaged, and which of these usually fits this product line.
For work where the requirements are genuinely settled. A written scope, a phased plan and a price we hold. Best for a defined build, a migration, a security engagement or a design phase.
Named engineers at a monthly rate, working on your board and in your repository. The right shape when the roadmap is still moving, which is most products after their first release.
Ongoing maintenance, monitoring response, dependency updates and a block of hours for changes, under a written arrangement agreed before launch rather than during an incident.
Where it is used
Sectors where we are asked for this artefact most often. It is a statement about the fit of the shape, not a client list.
How the work is run
This page describes the artefact. Scope, delivery model and engagement terms live on the service pages, which is where they belong — follow whichever applies rather than reading it twice.
Questions
Yours, always, and we set them up with you rather than for you. The app, the signing certificates, the keystore and the store listings are assets you must own outright — if they sit in an agency account, changing agency later means republishing as a new app and losing your reviews and installs. We hold access while we work and hand it back with the credentials documented.
Often, and the first piece of work is an honest read of what exists: whether it builds from a clean checkout, whether the dependencies are still supported, whether the signing material is available, and what the crash rate actually is. That read takes days rather than weeks and ends in a written recommendation to continue, refactor in place, or rebuild. We have said all three.
Mostly by avoiding the common causes before submission: missing privacy declarations, permission prompts with no stated reason, account deletion not offered in-app, payment flows that route around the store, and screenshots that do not match the build. When a rejection does arrive it is usually a clarification rather than a redesign, and we handle the correspondence.
We build one. A mobile product almost always needs an API of its own rather than talking directly to a database or to your ERP, because the app needs a stable contract that does not change when an internal system does. That layer is part of the build, and it is the same layer a later web application can use.
We target iOS 15 and Android 8 as a default floor, which covers the overwhelming majority of devices in use in India, and we test on genuinely low-end hardware rather than only on a recent flagship. If your users are on something older we will say what that costs, because supporting a much older Android means giving up several current libraries.
Also in products
Web platform
A signed-in system in the browser: records, roles, state changes and an audit trail behind them.
SaaS product
A multi-tenant product with the boring half finished: tenancy, billing, onboarding and the admin console.
Describe what the finished thing has to do and who has to use it. We will tell you which parts of a mobile applications build are the expensive ones in your case, and where a smaller first release would get you most of the value.
What happens next
