Everything from one team
Design, build and operations with the same team, from the first call to launch.
Mobile app development, with the cost after launch named up front
iOS and Android from one React Native codebase. We handle both store submissions, rejections included: fixing one and sending it back in is on us.
12+ projects delivered
every one on deadline, in production
Fixed price and deadline
in writing, and if we slip, the next payment waits
Reply within 24 hours
on working days, to every enquiry
In writingQuoted after scoping
One codebase, two platforms, store submission included.
What the idea does not cover
The budget is planned up to launch. The maintenance bill starts after it.
App Store review sends the submission back, and nobody can tell you what the problem was.
The app gets installed, and a month later the users have deleted it.
The path from code to store
- 1One codebase, so a single fix reaches both platforms in the same round.
- 2We assemble the App Store submission, screenshots and privacy forms included.
- 3The same release goes into the Play Store, with the same listing.
- 4If review sends the submission back, the fix and the resubmission are ours.
Which of these is your project
App for work in the field
People working on site fill in a job sheet, take photos and collect a signature, with or without a connection.
Customer app on the system you already run
The service you already run on the web, on a phone: sign-in, the customer’s own data, and a push when something happens.
Mobile companion to a web app
Your system stays on the web, and only the few screens people use on the move go to the phone.
First version for a market test
The first version with the one process that matters, on a few screens, so real users tell you what to build after it.
1.93 million
submissions were rejected by App Store review in 2024, out of 7.77 million. A rejection is routine: fixing it and resubmitting is part of the job here.
Apple, 2024 App Store Transparency Report.
Companies we've built for
Gloster
Palm Group
Habibi
The Garage
Design Glass
Kék Padlizsán
Jungle Burger
D+D Solar
Fawa
On every project
Your goal sets the bar
The first call is about what you want to achieve; if less will get you there, we say so.
Tested before it goes live
We measure what we hand over before launch, and watch the first week with you, measurements included.
What a mobile app project includes
- iOS and Android, released together
- Push notifications, tied to real events
- Offline use, with no signal at all
- Submission to the App Store and Play Store, in your account
- Wired into the system you already run
What the app is built with
How the app ships to both stores from one codebase
- Call
We walk the screens
We look at what has to work offline and whether it needs a native module. At the end we say if a web app would do instead.
- Scoping
A written proposal, screen by screen
We write down which screen ships when and what goes into the store submission. That price holds until submission.
- Build
One codebase, two platforms
The same code ships to iOS and to Android. You try the test build on your own phone through TestFlight and the internal track.
- Live
Submission, and life after the store
We submit to both stores under your own accounts.
Who a React Native app fits, and who it does not
This fits you if
- Your customers need push notifications and offline use, which a browser will not give them.
- You want one team carrying iOS and Android from one codebase.
- The app sits on a system you already run and has to connect to it.
We would point you elsewhere if
- A responsive web app does everything you need. Then we build that, faster and for less.
- Heavy 3D, continuous background audio or rare hardware is the main feature. We recommend native there, even when we are not the ones building it.
If the app works fine in a browser, a web application is the cheaper route.
How we work
A mobile app from design to store listing
- Clickable progress on a live link, stage by stage
- Fixed price and deadline, in writing
- The code and the infrastructure are yours
- Monthly maintenance after launch: updates, fixes, extensions
- If we slip, the next instalment waits
The proposal is itemised: what we build, by when, for how much.
In writing
Quoted after scoping
One codebase, two platforms, store submission included.
The feature set, and whether it needs a native module. App Store and Play Console developer fees are a separate line, in your name.
Get a fixed-price quoteWhat happens after launch
iOS and Android ship a new version every year and the stores move their requirements with them, which is most of what maintenance means here.
First month
A clean handover, a watched launch
Source code, credentials and documentation in your hands. We watch the first week with you, measurements included.
Every month
Maintenance that keeps it moving
Updates, fixes, extensions, and the measurements watched as your product grows.
If something breaks
You write, we answer
A first reply within 24 hours on working days, to every enquiry.
Stores, native builds and the cost after launch
Three things decide it, and you can check all three yourself. A web application is enough when people open it from a link, when a browser tab is an acceptable home for it, and when nothing has to work without a signal. You need an app when it belongs on the home screen, when it has to send a notification on its own, or when it has to work offline. After that the call is about screens rather than about whether to build one at all.
The price list says "Quoted after scoping": the number of screens, offline behaviour and the integrations decide it. After the first call you get an itemised proposal with an agreed figure. The two yearly developer accounts are not in it, and that is deliberate: they are registered in your name, so the app and its store presence stay yours.
Yes, considerably, and sometimes that is the right purchase. Builders and wrappers work where the app is a shell around content you already publish and the screens are the platform's screens: news, a catalogue, a simple shop. They handle the store submission too, often under your own accounts. Bring in a developer where the app has to do what your business does: your data model, your integrations, your rules. And where you would rather a platform's pricing change did not rewrite what your app can do.
React Native covers most business apps: lists, forms, payments, maps, camera, push. We move to native when heavy 3D, continuous background audio, real-time video or audio processing, augmented reality, advanced biometrics or a permanent link to an external device is the point of the app. If that is what you need, we say so on the first call.
Yes. The developer accounts are in your name (Apple charges 99 dollars a year, Google 25 dollars once) and we submit as invited collaborators. For a company account Apple also asks for a D-U-N-S number and your registered company details: the D-U-N-S is free, but it does not arrive instantly, so it is worth starting with. Screenshots, listing copy and the privacy forms are ours as well, and we fix whatever review sends back.
Yours. The App Store and Play accounts are registered to your company, so the app, the code and the store presence stay yours even if you continue with another team one day. The reviews, the download history and the earlier versions stay where they are too: in your account.
Once a year the platforms change a rule or an API that needs work. The maintenance plan covers SDK upgrades and store compliance, so the app still opens after the next major release.
A mobile app keeps costing after launch: the operating systems change every year, so do the store rules, and the submission has to run again. So we quote monthly maintenance alongside the build, and you see the yearly figure up front. The code is yours, so another team can take it on.
Start with the screens
Half an hour tells us how big the first version is, and whether a web app would solve it for less. Then the proposal follows.