What this covers
You’ll have one Flutter codebase running cleanly on iOS and Android, wired to your backend, tested on the phones your users actually carry, and ready to ship with a handover your team can safely extend.
We’ll build your Flutter app against your existing backend, test it on real phones, and take it through App Store and Google Play submission. This proposal covers the build, the rollout, and what it costs.
We start with a short discovery and tech plan workshop, then build the cross-platform MVP in Flutter with API wiring, offline caching where it matters, and a QA pass on a defined set of real devices. You’ll get weekly check-ins with what shipped, what’s next, and what’s blocked, so decisions stay small and the timeline stays readable.
About us
We’re a three-person mobile team that builds cross-platform apps for iOS and Android, usually for teams that already have a backend and need the app to catch up fast. We came up through shipping production Flutter and React Native apps, then ended up specialising in the part that breaks schedules most often: API wiring, edge-case handling, and release day.
People pick us when they want a build that stays under control week to week. We write a tech plan before we write screens, we keep the app structure simple enough to maintain, and we don’t hide behind vague updates. If something is risky, we name it early, show options, and agree the tradeoff in writing before it turns into rework.
Who you will work with
You’ll work directly with the three of us, and you’ll see the same names from planning through testing and store release.
Team
Omar Al-Hassan, Tech lead. Omar owns the app architecture, code reviews, and the parts that decide whether the app stays maintainable after the first release.
Lina Qasem, Flutter engineer. Lina builds the UI from Figma, handles state and navigation, and makes sure the app behaves the same way across iOS and Android.
Yousef Abu Rumman, QA and release. Yousef runs the device test pass, writes reproducible bug reports, and takes the build through App Store and Google Play submission.
Selected work
Here are a few examples of the kinds of cross-platform builds we get asked to take from “working backend” to “shipped app”.
Field Ops Checklist App
Built a Flutter app for crews moving between sites, with offline-first forms, photo capture, and a sync queue so work still records when reception drops.
Pilot Booking MVP
Shipped an MVP for a time-sensitive pilot with login, booking flows, and payments, then tightened the release process so hotfixes could go out without drama.
Customer Portal Mobile UI
Implemented a Figma UI in Flutter and wired it to an existing API, with caching and clear error states so users don’t get stuck on a spinner.
“We were worried the app would only work on the team’s phones. The weekly builds and real-device testing caught issues early, and the handover was clean.”
Product owner, a pilot-stage software team
Flutter app source code
One codebase for iOS and Android, structured for maintainability, with clear modules and naming so a new developer can find things without guesswork.
UI BUILT FROM FIGMA
Screens and components implemented to match your Figma file, including empty states, loading states, and error states so the app stays usable when data is slow.
API INTEGRATION LAYER
A clean API client, request and response models, and retry rules. We wire it to your existing backend and document any endpoint gaps we find.
Offline caching and sync
Local storage for the data that needs to survive bad signal, plus a sync approach that makes conflicts visible instead of silently overwriting work.
FIREBASE AUTH AND NOTIFICATIONS
Firebase Authentication setup and push notifications, with the app receiving and handling notifications in the ways iOS and Android each require.
STORE-READY RELEASES
Signed builds for App Store and Google Play, plus the store listings metadata you need to submit. We stay on hand through review and first release.
What it costs
Pick the tier based on how much product surface you need in the first release. Every option includes iOS + Android builds, real-device QA, and store submission.
Priced items
Getting started
If the scope and timeline fit what you’re aiming to ship, sign below and we’ll book the workshop and start the build plan.
1. Sign and return this proposal. 2. Share API docs, a staging environment, and your Figma link. 3. Join the discovery and tech plan workshop to lock the first build.
Signature
Fee summary
Can you use our existing backend, or do we need one?
We can use your existing backend. In the workshop we map the key user flows to the endpoints you already have, then call out any gaps, auth issues, or data shape changes before we start building screens around them.
WHAT DO YOU BUILD IN FLUTTER VS REACT NATIVE?
This proposal is for Flutter. We use Flutter when you want one codebase with consistent UI behaviour across devices. We use React Native when you already have a strong JavaScript stack or need to share code with a web app.
Which phones are you testing on, exactly?
We test on a defined set of real iOS and Android devices, agreed before the build starts, plus emulators for quick checks. We’ll list the exact models in the tech plan so “tested” means something specific.
WHO FIXES BUGS AFTER WE SHIP, AND HOW FAST?
We do, if you want us to. After launch we can run a support retainer with a clear response window, or we can work ticket-by-ticket. Either way, you’ll see a reproducible report, a fix branch, and a release note.
Payment
We take 40% to start, 40% at the first end-to-end working build, and 20% on store submission. Invoices are due within 7 calendar days by bank transfer.
Scope changes. If you add or change screens, flows, or API behaviour mid-build, we’ll write a short change note with the added cost and time before we start. Nothing moves ahead on a verbal OK.
What we need from you. Before we start build work, we need your Figma link, API base URLs, and test credentials. If the backend is still changing, we need one person who can answer API questions within 1 business day.
Weekly check-ins. We run a weekly check-in and send a short update: what shipped, what’s next, and what’s blocked. When something is blocked on backend access or answers, the timeline pauses until it’s unblocked.
Devices we test on
We QA on real devices, not only simulators. We’ll confirm the exact device list at kickoff, and we’ll cover at least 2 iPhones and 2 Android phones across small and large screens.
Bug fixes after release. For 30 days after release, we fix bugs in the shipped scope at no extra cost. We aim to respond within 1 business day and ship fixes in the next patch release when possible.
Ownership. Once the final invoice is paid, you own the Flutter source code we wrote for this app. We keep the right to reuse our own general utilities and patterns that don’t include your code or data.
Store submission. We handle App Store and Google Play submission using your developer accounts. If a store rejection needs product or policy changes, we’ll explain the reason and quote any extra build work before doing it.
