01
Customer facing apps
Ordering, booking, tracking and account management, with push notifications that arrive when they are useful rather than constantly.
Mobile app development
One codebase, both app stores,no second team.
Android and iOS from a single React Native build, with store submission and signing keys handled rather than billed to you later.
The problem
Why do mobile budgets vanish so quickly?
Because the same app quietly gets built twice, and the store submission nobody quoted for arrives at the end.
How it usually goes
- Two teams, two codebases, two sets of bugs
- Store submission discovered as an extra at the end
- Signing keys held by whoever built it
- Works on the simulator, fails on a real phone
- Offline behaviour added late, so it never quite works
- No plan for the next Android or iOS release
How we do it
- One codebase, one team, both stores
- Store submission included, not billed later
- Signing keys and store accounts in your name
- Tested on real devices before you ever see it
- Offline designed in from the first architecture call
- Store policy and OS updates handled as they land
How it works
One codebase to both stores
The same source produces the Android and the iOS build, so a fix is written once and lands on both platforms in the same release rather than drifting apart over a year.
- 01
One codebase
- React Native
- TypeScript throughout
- 02
Two builds
- Android and iOS
- Built from one source
- 03
Store review
- Listings and policy
- Handled by us
- 04
On the device
- Offline friendly
- Tested on real phones
- 05
Updates
- Fixes over the air
- No store wait
Ship again, back to One codebase
Mobile app development
What we build most often
02
Field and delivery apps
For teams working away from a desk and often away from signal. Built offline first, so work continues and syncs when the connection returns.
03
Internal staff apps
Attendance, inspections, stock counts, site reports. The paperwork that currently travels back to the office as photographs in a WhatsApp group.
04
Companion apps for an existing platform
Where you already have a web application and need the phone to do a specific subset of it well, rather than mirroring the whole thing badly.
05
Apps with payments built in
UPI, cards and wallets through Indian payment gateways, with the reconciliation and failure handling that actually keeps accounts straight.
06
Rescue and store compliance work
Apps stuck in review, rejected for policy reasons, or unable to release because the original developer is gone and nobody holds the signing keys.
A fix written once should reach Android and iOS in the same release.
As standard
In every build, not quoted separately
- 01Android and iOS from one codebase
- 02Play Store and App Store submission handled
- 03Offline friendly behaviour by design
- 04Tested on real devices, not only simulators
- 05Signing keys and store accounts in your name
- 06Crash reporting and release monitoring set up
The timeline
What a typical app project looks like
Store review is the one step nobody controls, so we plan for it rather than discovering it. Everything before it sits on a date you agreed.
- Week 1
Requirement gathering
Who uses the app, where, and what must keep working when the signal drops.
- Week 2
Scope and price signed
A written scope and fixed price, with store submission included rather than excluded.
- Weeks 3 to 4
Design and architecture
Screens, offline behaviour and the sync model agreed before any code exists.
- Weeks 5 to 10
Build, demoed weekly
A test build on your own phone every week, not a screenshot in an email.
- Weeks 11 to 12
Store review and release
Listings, screenshots and review responses handled, in store accounts you own.
- Week 1
Requirement gathering
Who uses the app, where, and what must keep working when the signal drops.
- Week 2
Scope and price signed
A written scope and fixed price, with store submission included rather than excluded.
- Weeks 3 to 4
Design and architecture
Screens, offline behaviour and the sync model agreed before any code exists.
- Weeks 5 to 10
Build, demoed weekly
A test build on your own phone every week, not a screenshot in an email.
- Weeks 11 to 12
Store review and release
Listings, screenshots and review responses handled, in store accounts you own.
Questions
Questions about mobile app projects
Scope decides it, so we quote against your written requirements rather than publishing a number that would be wrong for most readers. What is fixed is the method: a scoping call, a written scope, then a fixed price and delivery date you approve before anything is built or paid for.
For the large majority of business apps React Native is the right answer, because the cost of maintaining two codebases outweighs the benefit of native code you will never notice. Fully native is worth it when the app lives or dies on heavy graphics, deep hardware integration or platform features that appear the week they are announced. We will tell you which situation you are in before you commit.
Yes, and it is part of the project rather than an extra. That includes store listings, screenshots, privacy declarations, review responses and the signing keys, all created in accounts that belong to you.
Apps need periodic maintenance to stay compliant with store policy and new operating system versions, and this is real ongoing work rather than a one time build. A support retainer covers it, but it is optional, and your code stays yours whether or not you keep one.
Tell us what the app has to do.
Describe who uses it and what they need it for. We will come back with what that means in software, with a fixed price and a date against it.