Flutter Developers in the UK

About Flutter Developers

Hire senior Flutter developers who build iOS and Android from a single Dart codebase, wire up the backend, push, and offline sync, and ship to both app stores. We are a small senior team in Noida, so you work directly with the engineer on your app, not an account-manager layer. Flat quotes, a written scope before any code, and your source in your own repo from day one.

What the engagement includes

• Senior engineers on your app from day one, with direct access to the person writing the code. No junior offshore pool behind an account manager relaying your questions.
• Flutter is in our real production stack, with two live apps shipped for Jai Shri Balaji Store, so a dedicated developer here is not learning the framework on your timeline.
• One codebase for iOS and Android, with both stores handled end to end: signing, listings, screenshots, data-safety declarations, and the review back-and-forth.
• Flat INR quotes on GST-compliant invoices for Indian clients, and USD, CAD, GBP, or AED via Wise for overseas teams, with W-8BEN and LUT on file.
• 70 plus projects shipped in total across all our work, for clients in India, the US, UK, Canada, and the UAE, so a launch is routine for us.
• You own the source code, the GitHub repo, and the App Store and Play Console accounts, all in your business name. Clean exit, no lock-in, 24-hour response.

Store accounts in your company's name, who sells to UK customers, and a Firebase project that stays yours

The first decision in a Flutter engagement is whose name the apps are published under, and both stores treat it as a question of legal identity rather than logins. Apple enrols an organisation only if it is a legal entity able to contract, and says it does not accept trade names, fictitious business names or branches; the organisation's name is then shown as the seller of every app. For a UK company that means the name on the Companies House register, so a business that trades under a brand will see its registered name on the store page, and the UK branch of an overseas group cannot enrol in its own right, so the account belongs to the legal entity the branch is part of. Apple verifies identity, legal status and address through a D-U-N-S number, which government entities are spared, and the person who enrols becomes the Account Holder and must have authority to bind the organisation, usually a director or someone a director has authorised. Google Play makes a D-U-N-S number mandatory for organisation accounts and expects an organisation account from anyone offering financial products, health apps or government apps, including apps built on behalf of a government agency. One Flutter codebase therefore needs two store accounts held by the same UK entity. The D-U-N-S check and Apple's verification run to their timetable rather than yours, so they start in week one, not when the first build is ready. Our engineers are then added as users, App Manager or Developer in App Store Connect and named users with scoped permissions in Play Console, never as Account Holder or owner, so the end of the engagement is a matter of removing access rather than moving apps. An account opened in an agency's name to save a fortnight is the arrangement that is hardest to unwind, because moving a live app between accounts is a transfer with conditions of its own. Who signs for your company is for your board.

Whose account it is also decides who sells to UK customers and who answers for the VAT. Apple's licence agreement appoints Apple Distribution International Ltd, an Irish company, as the developer's commissionaire for end users in the United Kingdom, and lists the UK among the territories where Apple collects and remits the taxes due on sales. Google states its position for Play plainly: it is the merchant of record for transactions with UK customers made through Google Play's billing system, and it determines, charges and remits VAT on paid apps and in-app purchases of digital content and services. The exception is one a product team can trigger without noticing. Where a UK customer pays through an alternative billing system, Google says the developer becomes the merchant of record and is responsible for any VAT due, so a Flutter app offering a web or third-party checkout beside the in-app purchase plugin turns the account holder into the seller for those payments. Google adds that a developer based in the UK pays no local VAT on Google's service fee but may need to self-assess it. Every one of those positions attaches to the account holder. If the apps sit in an account held by a company in India, the proceeds, the payout statements and any merchant of record liability on alternative billing all belong to that company, and getting your own sales income back from it becomes a cross-border payment with tax questions in two countries. Held by your UK company, the proceeds land with you and the payout reports reconcile against your own books. In the code, the billing path is a decision recorded per storefront, so alternative billing for UK users is switched on deliberately and with your finance team's agreement, never because a plugin defaulted to it. How the proceeds and service fees are treated in your VAT return is for your accountant.

Most Flutter apps also run on a Firebase project, and that is the third thing to create in your name before an engineer writes the first line. Crashlytics, Cloud Messaging, Remote Config, Analytics and Authentication all sit inside one project, and the project belongs to whichever Google account or organisation created it. Created under your Google Cloud organisation, it stays with you and our engineers receive scoped roles; created by a developer in a personal account, the project holding your users' push tokens and sign-in records is theirs until somebody moves it. Location is the part that cannot be put right afterwards. Firestore asks for a location when the database is provisioned, lists europe-west2 in London among them, and Google's documentation says that once a database instance is provisioned its location cannot be changed. A database scaffolded in a hurry in whatever location the console suggested keeps that choice for life, and correcting it means a new database, an export and import, and a release of every client that points at the old one. For a UK business whose privacy notice or customer contracts say where data is held, that is a conversation to have before the first sprint, with whoever signs off data residency on your side. So the project, its billing account and its database location are settled in week one, and the configuration files the Flutter build reads, google-services.json and GoogleService-Info.plist, are generated from your project rather than ours. Signing follows the same rule. Apple distribution certificates live in your team, the Android upload key and Play App Signing are set up under your Play Console account, and the keystore sits in your secret store rather than on a laptop, so a release can be cut without anyone on our side if it ever has to be. Whether a given location satisfies your contracts or privacy notice is for your own counsel.

How we work with UK clients

UK engagements tend to start with procurement questions rather than technical ones. Who holds the data, which law governs the contract, whether you can produce a record of processing if the ICO asks. We answer those in the proposal instead of leaving them to a legal review three weeks in, because that review is where UK projects usually stall.

Invoicing is the other thing worth settling early. We are outside the UK, so services we supply generally fall under the reverse charge and your finance team accounts for the VAT rather than paying it to us. Our invoices say so explicitly. We quote in pounds, the figure does not move with the exchange rate mid-project, and payment by bank transfer avoids the card fees that make a five-figure invoice unnecessarily expensive.

Questions UK clients ask

Flutter Developers: common questions

Other markets we work in