We build mobile apps for iOS and Android from one codebase, in Flutter or React Native, with the sign-in, back end and push messages they need. We also take an app through App Store and Google Play submission, and repair one that was turned down. It is built in your developer accounts, and the source code is yours.
Tell us what you needSee typical projectsAgreed in writing first, then built and handed over to you.
What we hear from businesses before a project like this starts.
The requests that come up most often for this kind of work, and what each one takes to work properly.
A single codebase in Flutter or React Native, so each feature arrives on both phones together and you look after one app, not two.
Records saved on the phone and synced when the signal returns, with a written rule for what happens when the same record was changed in two places.
Email, phone, Google and Apple sign-in, password reset and deleting an account from inside the app, which both stores expect.
Notifications on both platforms, with the permission request shown at a sensible moment and a record of what was sent to whom.
The database, the API and a web page for your team, built in your own cloud account with backups and a test copy.
Field forms, photos and signatures filled in on site and filed to the right job when the tablet syncs.
Developer accounts in your name, listing text, screenshots, privacy answers and reviewer notes prepared, builds uploaded and a test login supplied for the reviewer.
The reviewer's note read line by line and the app and its listing changed to match: subscription wording, account deletion, privacy links, permission explanations. Then resubmitted.
The code read, run on real devices and written up, the missing features finished and a pre-launch bug pass done before it goes to review.
Tools that come up most: Flutter, React Native, Expo, Swift and Kotlin where a feature needs them, Firebase, Supabase, Postgres, Node.js, App Store Connect, Google Play Console, TestFlight, Stripe, Sentry.
Concrete pieces, each one something you can open and check when it's done.
The screens and logic for the one job the app exists to do, built once and run on iPhones, iPads, Android phones and tablets.
Flutter or React NativeSign-in, roles, password reset and account deletion, with sign-in with Apple added where the store rules call for it.
Firebase Auth, Supabase AuthData kept on the phone, changes queued and sent when the signal returns, and the conflict rules tested with the phone in airplane mode.
Local database, sync queueMessages to iPhone and Android with topics, quiet hours and a log of what was sent.
Firebase Cloud Messaging, Apple push serviceThe database and API in your own cloud account, with a web page for your team to see and edit records.
Supabase, Firebase, Postgres, Node.jsIn-app purchase or subscription where the store rules require it, and Stripe for physical goods and services, which the rules treat differently.
In-app purchase, StripeListing text, screenshots, privacy answers, a reviewer login and the notes that explain how to reach each feature.
App Store Connect, Google Play ConsoleTest runs on real phones and tablets, a written test log, and crashes sent to an inbox so a broken release is known the same day.
TestFlight, Play internal testing, SentryExample packages to show the shape of the work. These are examples, not past clients; yours gets its own written scope.
Example package
The one core flow running on an iPhone and an Android phone, so you can hold it and decide what comes next.
You get
Example package
An app that keeps working without a signal and catches up afterwards.
You get
Example package
Your finished app prepared and submitted to the App Store and Google Play.
You get
Example package
An app that was turned down, changed to meet the review note and sent back.
You get
The habits that keep this kind of project from going wrong.
We build both phones from one codebase, and say in the scope where a feature really needs separate native code.
Features are tried on real devices, not only on a simulator, including a phone with the signal switched off.
Account deletion, privacy answers, permission wording and subscription disclosures are designed in, because they are the usual reasons for a rejection.
The developer accounts, the repository and the cloud project are in your name from the first day.
A written scope first, then working progress you can check, then a proper handover.
Tell us what you need in your own words, and which tools you already use. A few lines is plenty to start.
We reply with a short written scope: what gets built, what is out of scope, which accounts we need, and how we'll both know it works. You know what you're getting before work begins.
The work is split into milestones. At each one you see it working in your own account and sign it off before we go on.
You get the working system, its documentation and a walkthrough. If anything we built breaks in the next 30 days, we fix it at no charge.
Pushbuild has built software for businesses since 2010, for more than 40 clients. Every project is led by a former public-company CTO, from Groton, Massachusetts. See example builds.
Both build one app for iPhone and Android. We recommend one in the scope based on your team, any web code you already have and the features you need, and we say why.
We prepare the submission and answer reviewers, but approval is their decision and we cannot promise it or say how long it will take. What we can do is build to their rules and repair what they ask for.
Yes. Send us the review note and the app. We tell you which points we can repair, change the app and the listing, test it and resubmit. If the note is about your business model rather than the code, we say that plainly.
It can. We decide with you which records live on the phone, how they sync and what happens when two people change the same one, and then test it with the phone offline.
Yours. Apple and Google accounts are set up in your name, so you own the apps and can move them. We guide you through the sign-up, which includes checks that Apple and Google carry out themselves.
Often the back end is reused and the screens are rebuilt for phones. Wrapping a website in an app shell is sometimes enough, but a store can turn down an app that is only a website, so we say which route is realistic.
It depends mostly on the number of screens and on whether the app works offline. The scope gives an estimate, and store review time is decided by Apple and Google.
For 30 days we repair anything we built that does not work as the scope describes, at no charge. After that, further work is scoped the same way and agreed with you before we start.
Do it once, we automate it. Show us the job one time and it runs on its own after that, in the tools you already use.
Email a few lines about what you want and which tools you use, or call. We reply with questions or a written scope.
hello@pushbuild.com