The first release was the whole plan
Store submission, device coverage and updates were treated as the end rather than recurring work.
Services / Mobile App Development
Mobile app development for products that have to survive the second release.
We build apps your team can keep shipping, with the store process, device testing and release path set up from the start.
Release path
Build 2.4.1
- MergedYour team
- Store reviewOutside your control
- Staged rollout10% of users
Remote config
A bad build is a switch, not a release
Three ways a mobile build gets expensive after launch.
Mobile is not automatically right. If the job is occasional and could run in a browser, a web application avoids store review, install friction and two release cycles.
It works on the phones the team owns
Older OS versions and low-bandwidth conditions were never in the test set.
Two codebases, one budget
Native on both platforms doubled maintenance without anyone deciding that was the trade.
What we take on.
Cross-platform apps
One codebase across iOS and Android where the product does not need platform-specific behaviour.
Native apps
Where hardware, performance or platform integration genuinely require it, rather than by default.
Apps against existing systems
A new surface on data and logic you already run.
Store submission and review
Preparing, submitting and getting through review, including the rejections nobody plans.
Release and update path
Staged rollout and a way to fix a bad build without waiting for another review cycle.
Device and condition testing
Real devices, older OS versions and poor connectivity, where apps actually fail.
Where this page stops. Browser-based applications belong to web app development. A 30-day first version for a founder belongs to Moonship MVP. Broader builds belong to custom software development.
Native, cross-platform, or web: the questions that actually decide it.
This choice is usually made on preference and paid for in maintenance. These five questions settle it more reliably.
Does it need hardware the browser cannot reach
- native
- Yes, deeply
- cross-platform
- Yes, in standard ways
- web
- No
How different are the two platforms' behaviours
- native
- Deliberately different
- cross-platform
- Essentially the same
- web
- Not applicable
How often will it change
- native
- Rarely, and correctness matters more than speed
- cross-platform
- Often, and one codebase halves the work
- web
- Constantly, and you want no release cycle
Who maintains it in two years
- native
- Two platform specialists
- cross-platform
- One team
- web
- Your web team
Does install friction matter
- native
- No, users want the app
- cross-platform
- No
- web
- Yes, and that is decisive
Most products that arrive asking for native fit the middle column. Where the last row is a yes, we say so even though it means a smaller engagement.
How a mobile build runs.
Settle the platform question first
Using the table above, before any design work, because it changes everything downstream.
Agree what the first release must do
Acceptance stated per feature, so completion is a check rather than a judgement.
Build for a real device set early
Test targets from your users' actual devices, not the latest hardware.
Get through store review once, properly
Metadata, permissions and privacy declarations prepared before submission, not after rejection.
Ship with a way to fix it
Staged rollout and remote configuration, so a bad build is a switch, not a review cycle.
Hand over the release process
Your team able to submit, roll out and roll back without us.
Mobile and app work with a published result.
30%
Faster trip acceptances
Milo. Fleet operations, where the app was the working surface for drivers.
38% faster product-question response
Conscious Chemist. Customer-facing product answers.
Those figures describe those engagements, not projections.
Read the Milo case study or see all case studies.
Building software people keep using.
0
Building software since
0+
Projects delivered
0 yrs
Longest running client integration
0
Countries served
Where mobile builds usually start.
Situations rather than industries. Published work covers fleet operations, consumer health and beauty; nineteen years covers more.
A field team on paper or messaging apps
Where the work happens away from a desk and the record is made afterwards.
A customer product that needs to be on a phone
Where the whole experience assumes a device in a hand.
An internal tool nobody uses on mobile
Where a web system exists but is unusable on the device people actually carry.
An app that stopped being updated
Where the original build shipped and then nobody could safely change it.
What an app costs to keep alive.
We raise this at scoping because it changes the platform decision. Two native codebases pays it twice.
- Annual
Two platforms deprecate on their own schedule
OS releases force changes whether or not your product changed. That is annual work, not project work.
- Ongoing
Store policy changes are not optional
Privacy declarations and permission rules shift, and non-compliance eventually removes the app.
- Per dependency
Every SDK is a dependency with an end date
Analytics, payments and push each age. A build with many is a build with many upgrade obligations.
- Continuous
Device coverage widens over time
The test set that was current at launch is not current two years later.
An app that nobody budgets to maintain is an app that quietly stops working, usually at the next operating system release.
How the technology gets chosen.
We are not tied to any framework; the choice follows the decision module.
- Framework
- Decided by the table above, not by preference. Something your team can hire for and maintain.
- Backend
- Usually what you already run. Building a new backend and a new app at once doubles the unknowns.
- Analytics and crash reporting
- Chosen for what your team will actually read, and set up before launch rather than after the first bad review.
- Distribution
- Store, enterprise or internal, decided early because it changes signing, review and update mechanics.
How the work is staffed.
Senior engineers on the build
The people scoping the work do it, which is what makes an estimate mean anything.
The same people throughout
Continuity matters more than headcount, because undocumented context lives with whoever built it.
Your engineers included
Working sessions rather than a closing handover document, because ownership transferred at the end rarely is.
Founder involvement on scope calls
Build-versus-buy and cut-versus-keep decisions reach someone who can make them.
We publish no team-size claim. Nineteen years and 500+ projects are verified; anything more specific belongs on the team page.
What you have when the build ends.
Handover is a two-sided arrangement, so both halves are set out before the work starts rather than discovered at the end.
What you have when the build ends
Source in your repository
Owned and readable, with history intact.
Store accounts and signing in your name
Not ours, which is what makes the next release yours to make.
The device and condition test set
Documented, so it can be extended rather than rebuilt.
Release and rollback runbooks
Written with your engineers, covering staged rollout and remote configuration.
A written list of what was not built
Deferred scope with reasons, so the next decision starts from the record.
Who we need from your side
Someone who can approve store metadata
Descriptions, screenshots and privacy declarations need a decision-maker, not a queue.
Access to your existing backend
Or a decision that one needs building, which changes the shape of the work.
A list of devices your users actually have
Even approximate. It sets the test targets and prevents optimising for the wrong hardware.
Someone who will own releases afterwards
Because handover is only real if there is somebody to hand to.
Where this work stops paying off.
We would rather scope down to a mobile-friendly web surface than sell a build that will not earn its keep.
A single internal form used monthly
An app is overhead. A mobile-friendly page in a system you run costs less and needs no store review.
A product with no decided platform strategy
Building before the decision module is answered means paying twice.
A prototype nobody has validated
Store submission, signing and device coverage are production concerns. Before a product decision they are premature.
Content that only needs reading
If nobody needs to act offline or use hardware, this is a web page and should stay one.
How this fits your existing release process.
Mobile adds a release path with constraints the web does not have.
Store review sits between you and users
A fix is not live when it is merged, and review time is outside your control.
How the build accounts for it
Remote configuration and staged rollout, so urgent changes do not need a review cycle.
Users run old versions indefinitely
Some people never update, so your backend serves several app versions at once.
How the build accounts for it
Versioned interfaces and a minimum-supported-version policy agreed before launch.
Crashes are reported after the fact
Unlike a server error, you often learn about it from a store review.
How the build accounts for it
Crash reporting configured before launch and routed to whoever can act on it.
Signing keys are a single point of failure
Lose them and you cannot ship an update to existing users at all.
How the build accounts for it
Keys held in your accounts, with the recovery path documented at handover.
What teams ask before they start.
Should we build both platforms at once?
Usually yes if cross-platform, because the marginal cost is small. Usually no if native, because it doubles a maintenance commitment before you know the product is right.
Can you take over an existing app?
Often. It depends on whether the source, signing keys and store access are available. Those three, not the code quality, are what decide it.
Who owns the store accounts?
You should, and we set them up that way. Where an app was previously built under someone else's account, retrieving it is the first task.
Do we need an app at all?
The last row of the decision table is the honest test. Where install friction is decisive, a web application is the better answer and we will say so.
Can you work with our existing engineers?
Yes, and that is the usual shape. Additional senior people run through our engineering bench. Broader questions are on our FAQ.
Tell us what the app has to do on day two hundred.
Most mobile problems are second-release problems. Describe what users do and how often it changes, and we will say whether native, cross-platform or web is honest.