Your first client, start to finish | Flangapp AI Docs

Documentation

Login to support

Your first client, start to finish

The rest of this documentation covers installing and configuring the platform. This page is the other half: what actually happens between a client saying yes and their app being live in both stores, in the order it happens, with the waiting periods marked so you can quote a realistic date.

Read it once before your first client rather than during. Two of the steps below have fixed delays that cannot be compressed, and both of them need to be started on day one.

Before you start

The platform should already be installed and through the Initial Setup Wizard: licence activated, GitHub and Codemagic connected, OneSignal configured. You should also have at least one plan and a payment provider connected, even if your first client pays you by invoice, because the plan is what grants their account access to build.

Step 1 — The client's store accounts (start this first)

This is the long pole, and it belongs to the client, not to you. Their app must be published under their own developer accounts, in their own name. That is not a preference: App Review Guideline 4.2.6 states that apps created from an app generation service are rejected unless submitted by the provider of the content, and that such services should not submit on behalf of their clients.

  1. The client enrols in the Apple Developer Program — $99 a year, paid by them, auto-renewing. An organization enrolment also needs a D-U-N-S number, which can take a few days to obtain if they do not have one.
  2. The client registers a Google Play Developer account — US$25, one time. Identity verification is required, and a personal account must also verify access to an Android device through the Play Console app.
  3. The client invites you into App Store Connect with the App Manager role, and ticks the separate checkbox for Certificates, Identifiers & Profiles. Without that checkbox you cannot handle signing, and it is the single most common thing to be forgotten here.
  4. The client adds you to their Play Console with the permissions to upload and release.

You do not need your own paid membership to work inside their account, and the invitation expires after three days, so send the instructions when the client is actually at a computer. The reasoning behind all of this, and what to say to a client who objects to the $99, is in do you need an Apple Developer account for every client.

Step 2 — The 14-day Android clock

If the client's Play account is a personal account created after 13 November 2023, Google requires a closed test with at least 12 testers opted in continuously for 14 days before the app can be released to production. Internal testing does not count toward it, only closed testing does.

Two consequences worth planning around. First, those fourteen days are the floor on your Android launch date, and the clock cannot start before the account and a first build exist — so get a build into closed testing early, even a rough one. Second, finding twelve real testers is the client's job and they will underestimate it: staff, family, regular customers. Ask for the list in week one.

Put the fourteen days in the written quote. A client told about them up front treats them as process; a client who discovers them in week three thinks you missed a date.

Step 3 — Create the client and their app

  1. Create the client's account on your platform and assign them a plan, or let them sign up and pay through your own checkout.
  2. Create the application from the client's website address. The platform creates a branch for that app in your connected GitHub repository and keeps its settings there.
  3. Fill in the app's general information — name, bundle identifier, description. The bundle identifier cannot be changed after the app exists in the stores, so agree it now, in the form the client will still be happy with in three years.

Step 4 — Configure it with Flangapp AI

Describe the changes in plain language rather than hunting through settings: design and template, side menu, navigation and bottom tab bar, permissions, splash screen, app texts, and hiding website elements that make no sense inside an app — cookie banners, a site header that duplicates the app's own navigation, newsletter pop-ups. The assistant can also restyle the site inside the app with custom CSS and JavaScript.

It works only within what the template can do, it never edits source code, and it cannot change the website's own content. See Flangapp AI for credits and model levels.

This is also the step that decides whether the app passes review. An app that is only a wrapped website is the classic Guideline 4.2 rejection — it needs to do something the website alone does not. Push notifications, native navigation and offline behaviour are the usual answers; the rule and what gets apps through is worth reading before the first submission rather than after the first rejection.

Step 5 — Preview on a real device

Before building anything, run the app through Application Preview — install Expo Go on a phone and scan the QR code. Do this with the client watching, on their own phone. Changes agreed at this stage cost a minute; the same change after the app is in review costs a new build and another review cycle.

Step 6 — Push notifications

Push is usually the feature that justifies the app's existence to the client, so configure and test it before launch rather than treating it as an extra. For iOS, prefer the APNs token-signing key over a push certificate: Apple's own documentation states that the token-signing key does not expire, while certificates add one more dated item to your calendar for every client you take on.

Step 7 — Build and submit

  1. Generate the release builds from the platform interface — AAB for Google Play, IPA for the App Store. No Mac, Xcode or Android Studio required.
  2. iOS: upload to the client's App Store Connect, complete the listing, privacy details and age rating, and submit for review. Review is normally measured in days, but treat it as unpredictable and never promise a client a launch date that assumes a first-pass approval.
  3. Android: upload to closed testing first if Step 2 applies, let the fourteen days run, then promote to production. New apps and updates must target Android 16, API level 36, under the requirement that took effect on 31 August 2026.
  4. Screenshots and the store listing are the client's marketing, not yours. Ask for their photos early — waiting on images is a more common cause of a late launch than anything technical.

Step 8 — Hand over, then diarise the year

Tell the client plainly that the app is theirs: it sits in their accounts, and if they ever leave you it stays on the stores under their name. It costs you nothing to say and it removes the lock-in suspicion that sits behind most objections at signing.

Then add three dates to a calendar you actually read:

  1. Three weeks before their Apple renewal. A failed card means the membership lapses and the app comes off sale, and the first you hear of it is the client asking why their app disappeared.
  2. Every August. Google raises the required target API level once a year. An app below the bar is not removed, but it stops being offered to new users on newer phones, which is a decline nobody notices until it is months old.
  3. Any client who has asked for nothing in three years. Apple's App Store Improvements process flags apps that have gone three years without an update and fall below a minimum download threshold. A version bump resets it.

What all of that costs to run across a whole client list is worked out in what twenty client apps cost to keep alive.