Hire Flutter developers who build one app for both phones

There is no rate card here, because the figure depends on how experienced the person needs to be and how much of the app they own end to end. What we promise is the shape. A half-hour call, then the work written down with a date and a price beside it, agreed before anybody starts. A developer sitting inside your team is billed per person per month. A defined build, say a first release in both app stores, is quoted as one job. Looking after it afterwards is optional and separate. Anything added later is quoted on its own and approved by you first.

Usually within 1 to 2 weeks, with the date written down beside the price so it is a commitment, not a hope. What speeds things up sits on your side: access to your code and designs, notes on the software the app must talk to, one person who can settle a question the same day, and Apple and Google store accounts registered in your company's name. If those accounts do not exist yet, signing up and getting verified takes its own time before any release can reach a tester. In the first week we push a throwaway change right through, because publishing is what catches phone projects out.

Flutter paints every screen itself rather than borrowing the phone's own buttons and menus. The gain: your app looks the same on both handsets and stays that way when Apple or Google restyle theirs. The cost: anything Flutter does not paint, such as a home screen widget or a watch app, needs a small piece of Apple or Android code. So it suits products with their own look and a lot of shared logic, and suits badly when the app is a thin cover over the phone's own features. We say so on the call. We would rather lose the work than build the wrong thing.

Yes. They commit to your code repository, follow your branching rules, take jobs off your board and wait for your approvals. Phone work adds a few things worth settling in the first week, so we settle them: which versions of the app exist, who holds the signing certificates, what goes in the release notes and who presses submit. If you keep notes on how the code is arranged, or a list of standard parts, we read those first and build to them. If none of that exists, we write down what we assumed and leave it beside the code rather than keeping it in one person's head.

Two routes, and you choose before submission, not after. Either your own team takes it on, with a walkthrough, the certificates, the release steps and an honest list of what we left unfinished. Or we stay on a monthly plan and keep cutting the releases. What makes phones different from a website is the wait. You cannot patch a handset the way you patch a page. A fix has to pass a store review before anyone gets it, and old versions stay installed on real phones for months. Somebody has to watch which versions people are running and keep the app buildable against the next round of phone software.

All three, and the accounts matter most. The code sits in your repository under your license from day one, plain Flutter with no wrapper of ours around it. The Apple and Google store accounts are registered in your company's name and we work inside them as invited guests, so the listing, the ratings, the reviews and your testers belong to you rather than leaving with us. The certificates that let a release be published live somewhere your own team can reach, with the recovery steps written down, because losing the Android one is painful to unpick. End the arrangement tomorrow and your next release still goes out.