Service business whose customers book by phone today
Bookings arrive after hours, staff retype them into 3 separate systems, and customers repeatedly request an app.
Put a working app in your customers' hands
We build iOS and Android applications for companies needing offline operation, push notifications, payments or hardware access, and we manage both store submissions.
What arrives
- Builds on TestFlight and Google Play internal testing from week 3
- Apps submitted under your own Apple and Google developer accounts
- Offline behaviour defined per screen, with the synchronisation rules documented
- Push notifications wired up, including the consent prompt and quiet hours
Who this is for
Three profiles. If none of them is recognisably you, this is probably the wrong page - and the line below is the one worth reading before you book anything.
Not a fit: Skip this if a mobile-friendly website would do the job, because an app adds store review, updates and 2 platforms to maintain.
Field operations manager with staff working off-site
Crews complete paper forms with no mobile signal, and the office waits 2 days to discover what happened.
Startup with a web product and mobile users
Most sessions already come from phones, and the responsive website cannot handle notifications, camera or background sync.
What you get
- Builds on TestFlight and Google Play internal testing from week 3
- Apps submitted under your own Apple and Google developer accounts
- Offline behaviour defined per screen, with the synchronisation rules documented
- Push notifications wired up, including the consent prompt and quiet hours
- Crash reporting and release tracking, so you see failures before reviews appear
- Store listing assets: screenshots, descriptions and privacy questionnaire answers
- A release checklist your team can follow for the next version without us
What we build it with
-
React Native
- Expo
-
Swift
-
Kotlin
-
Firebase
-
Supabase
-
Sentry
- Fastlane
Chosen per project, not per fashion. If your team already runs something else and it works, we use that.
How the work runs
-
1
1-2 weeks
Flows and screens
We map every screen and the journeys between them, then agree what operates offline before any code exists.
From you: Your current booking or job process, described step by step, including the exceptions.
-
2
1 week
Store setup
We take a seat in your Apple and Google accounts, configure signing, and get certificates operational early.
From you: A company Apple Developer account and a Google Play account, both in your name.
-
3
8-14 weeks
Build and test
We release a build to your testers every 2 weeks, on physical devices, including a slow Android handset.
From you: 3 to 5 testers who will actually install the build and report what broke.
-
4
1-3 weeks
Submission
We prepare the listings, answer the privacy questions, and handle rejections, which are common on a first submission.
From you: Your privacy policy, a support email, and a demo account reviewers can sign in with.
-
5
4 weeks
First updates
We monitor crash rates and store reviews for a month, then ship the corrections that real users expose.
From you: Someone who reads store reviews weekly and forwards what customers complain about.
How we work together
Fixed project
Scope and price agreed up front. Best when the outcome is known and the deadline is real.
Dedicated team
A named team for a quarter or more. Best when the roadmap will change and you want the context kept.
Staff augmentation
Engineers inside your process and your tools. Best when you have the lead and need the hands.
Invoiced in
- USD
- EUR
- GBP
- CHF
- SGD
- AUD
- CAD
- AED
- SAR
- QAR
- JPY
- INR
Paid by
Card, netbanking, wallet and UPI through Razorpay, which is what our checkout runs on, so anything it accepts we accept. Bank transfer, SEPA, Wise and Payoneer for invoices that prefer it.
NDA before the first call. Full IP assignment on delivery. Contracts under Indian, English or Delaware law.
Work like this
Case studies are being written up
Three are in legal review. We can walk you through the work on a call in the meantime, including the parts that did not go to plan.
What clients say on Google
Live from our Google Business listing - not retyped here.
Loading reviews from Google - read them on Google.
Questions we get asked
No, a single React Native codebase usually covers both platforms, unless the app needs deep hardware work. Shared code keeps 2 platforms in step and removes most of the duplicate work. We go native in Swift or Kotlin when the app leans on Bluetooth, heavy camera use or background location. We tell you which in the first 2 weeks.
Yours, always. Apps published under an agency account are hard to move and can vanish if the relationship ends. We ask you to open an Apple Developer account and a Google Play account in the company name, then add us as members. You can remove our access the day we finish.
We fix it and resubmit at no additional charge, because handling review is part of the work. Initial submissions are often rejected over sign-in options, privacy labels or a missing demonstration account. Most appeals resolve in 2 to 5 days. We plan for 2 rounds of review rather than treating rejection as a surprise.
Updates go out as new store releases, and your team can run them once we hand over. We set up Fastlane so a release is a single command, and leave a checklist covering version numbers, release notes and staged rollout. Some teams keep us on a monthly retainer; others take it in-house after 2 releases.
It costs a trade, not a surprise invoice. We estimate the new feature in days, and you decide whether it replaces something in the queue or extends the schedule. Changes that touch both platforms, offline synchronisation or payments cost more than screen-level changes, and we say which kind before starting.
Ready to put it on phones?
Describe the job your application must do, and we will tell you whether React Native fits it.