Summary
A v1 mobile app that behaves on real phones, gets through store review, and gives you a codebase you can keep shipping on after launch.
I’ll take you from a signed-off prototype through build, testing on real devices, and App Store and Google Play submission. You’ll end up with an app that people can log into, use, and update without drama, plus a codebase someone can safely extend after v1.
I’ll start by locking the screens and flows in a clickable prototype, then build the foundations first: auth, onboarding, and the data model. From there I connect your API, add offline sync where it matters, and put every change through TestFlight and Play Internal testing before I prepare the release build and submit to the stores.
Who you are working with
I’m Euan Baxter, a mobile app developer. I build iOS and Android apps for teams that need to ship without turning their product roadmap into a hiring plan. I do the work end to end, so the person you agree scope with is the same person making the build choices, fixing the edge cases, and preparing the store submissions.
I get picked when the priority is a stable first release that stays stable after the first update. I keep scope tight enough to ship, I test early on real devices because simulators miss the crashes you only see in the wild, and I leave projects with a build pipeline, readable code, and handover notes that make the next version straightforward.
Recent projects
A few recent builds that show the kinds of apps I ship, and the kinds of problems I’m used to unpicking before launch.
Portfolio
Subscription app launch. Built a cross-platform v1 with login, subscriptions, and push notifications, then ran internal testing and store submissions. The first release shipped with weekly updates for the first month, without breaking sign-in.
Existing web service app. Turned a working web product into a mobile app by reusing the backend and adding offline-friendly caching for the most-used screens. Support tickets dropped because people could finish tasks without perfect signal.
Native performance rebuild. Rebuilt a slow, crash-prone app screen by screen, starting with login and the busiest lists. App start time and scroll performance improved enough that the team could add features without fear of regressions.
“The app shipped on time, and updates haven’t broken logins since launch.”
Product manager, a small software firm
Clickable prototype
A tap-through prototype of the key screens and flows for sign-off. This is what I build to, and what you can share internally before any code is written.
IOS AND ANDROID APP BUILD
A production-ready app built as native iOS/Android or cross-platform, based on what best fits your scope and timeline. You get a working build throughout, not a surprise at the end.
API INTEGRATION LAYER
The app wired to your backend, with clear handling for errors, timeouts, and version changes. This is where most “works in a demo” apps fall over, so it gets extra attention.
Auth, onboarding, and core flows
Login and signup, onboarding, and the main user journeys agreed in the prototype. These land early so you can test the real app behaviour straight away.
TESTFLIGHT AND PLAY TESTING BUILDS
Internal testing builds you can install on real devices as development progresses. Each build comes with short release notes so you know what changed and what to try.
STORE SUBMISSION PACKAGE
A release build prepared for App Store and Google Play, with submission handling. I’ll work through review feedback if either store asks for changes during the submission.
What it costs
These are starting points. I’ll confirm the tier after the prototype is signed off and the v1 flows are locked. Prices are per month.
Priced items
Next steps
If you want to move ahead, I’ll lock the scope in the prototype first and then start the build with a clear first testing date.
1. Sign and return the acceptance page for this proposal. 2. Pay 50% of the setup to book the start date. 3. Share access to the API docs, test accounts, and any existing designs, and I’ll begin.
ARE YOU BUILDING NATIVE IOS/ANDROID OR CROSS-PLATFORM, AND WHY?
I can do either. If you need one codebase and a fast v1, I’ll usually recommend Flutter or React Native. If you need platform-specific features, the best performance, or complex background behaviour, I’ll recommend native. I’ll explain the trade-offs before we start.
WHAT DO YOU NEED FROM US TO START, AND WHAT CAN WAIT?
To start, I need access to your existing product, a short list of must-have v1 flows, and someone who can sign off the prototype. Credentials, analytics, copy, and exact store listings can wait until we’re testing real builds, as long as we set deadlines for them.
Signature
Fee summary
How do we handle logins, payments, and push notifications?
I’ll use your existing auth where possible, then add the mobile pieces: secure token storage, session refresh, and clean failure states. For payments, I’ll match your model to App Store and Google Play rules before I write code. Push notifications get built and tested early so they do not block release.
WHO OWNS THE CODE AND WHAT HAPPENS AFTER V1 SHIPS?
You own the code and the app store accounts. I hand over the repo, build instructions, and the keys and configs needed to ship updates. After v1, I can stay on for maintenance and version updates, invoiced at the start of each month, or I can support a handover to your in-house developer.
Payment
For one-off mobile app development, I invoice 50% to start and 50% when I hand everything over. For ongoing maintenance and version updates, I invoice at the start of each month. Invoices are payable within 7 days.
Scope changes. Once the clickable prototype is signed off, it becomes the build scope. If you add or change flows after that point, I’ll price the change in writing and wait for approval before I start the extra work.
What I need from you. To start, I need access to your existing product, a short list of must-have v1 flows, and one person who can sign off the prototype. I’ll also set due dates for credentials, copy, analytics, and store listing text.
Reviews and sign off. I’ll send links to the prototype and testing builds for review. I need consolidated feedback from one place, and a clear yes on each milestone, so I do not build on top of decisions that later change.
Accounts and access
You’ll provide Apple Developer and Google Play Console access for testing and release. If you prefer, I can submit using your accounts while you keep ownership and admin control. I do not create or own store accounts for you.
Testing builds. Testing happens through TestFlight and Play Internal testing. You’ll need at least one iPhone and one Android device available for real-world testing, because some issues only show up on-device and not in simulators.
Handover and ownership. You own the code and the app store accounts once the final invoice is paid. I hand over the repo, build instructions, and the keys and configs needed to ship updates, so another developer can pick it up safely.
Store review timing. App Store and Google Play review times are outside my control. I’ll handle the submission package and respond to reviewer questions, but a launch date needs a buffer in case a store asks for changes or extra information.
