Before Any Code Is Written: The Week-One Package, Cost Lines, and Six Irreversible Decisions on a From-Scratch Mobile Build

What a founder actually receives in week one

Week one of a from-scratch mobile build produces paperwork and decisions, not screens. The deliverables are an account and ownership checklist, an entity and event model, a screen inventory with week mapping, a decision register covering the six irreversible choices, and a first-year cost sheet. No production code ships in week one, and that is deliberate.

The reason is sequencing. A bundle identifier is written into signing certificates, push notification configuration, deep link entitlements, analytics properties, and the store listing itself. If the identifier changes in week six, the app is a new app as far as Apple and Google are concerned. Same for the data residency region: moving a Firestore database between regions means exporting, re-importing, and re-pointing every client. Week one exists so the expensive-to-reverse things get chosen while they are still free to change.

In practice the week-one package fits in a shared folder with five documents plus a spreadsheet. The spreadsheet is the one founders return to most: it carries the screen inventory, the week mapping, and the cost lines. Everything else is read once and then referenced when someone asks why a decision was made.

• • Account and ownership checklist: Apple Developer Program enrolment status, Google Play Console, D-U-N-S lookup result, role assignments, who holds the recovery email and 2FA device
• • Entity and event model: the nouns and the things that happen to them, agreed before schema design
• • Screen inventory: every screen named, with a complexity band and the week it lands in
• • Decision register: the six irreversible decisions, the option chosen, and the reason, dated and signed off
• • First-year cost sheet: recurring platform and infrastructure lines separated from one-off build cost
• • Non-goals list: what is explicitly out of scope for v1, written down so it stops being relitigated in week nine

The Apple and Google account setup checklist (and the part founders get wrong)

The client company must own both developer accounts, with the agency added as a member or admin, never the reverse. An Apple Developer Program organisation enrolment costs 99 USD a year and requires a D-U-N-S number for the legal entity; Google Play Console is a one-time 25 USD registration. Getting ownership wrong is the most common week-one mistake we see.

The D-U-N-S number is the part that blocks calendars. Apple requires it for organisation enrolment, and if your company does not already have one you request it through Dun & Bradstreet. Apple's own guidance allows up to five business days for the lookup, and newly registered companies in smaller EU jurisdictions routinely take longer because the registry data has to propagate first. We now start the D-U-N-S request before the contract is even countersigned, because it is free, it expires nothing, and it is the one item on the checklist that no amount of engineering effort can accelerate.

Two ownership shapes cause almost all of the pain we have had to unwind. The first is an Apple enrolment made under a personal individual account, which means the store listing shows a person's name rather than the company, and there is no supported path to convert an individual enrolment into an organisation one. The fix is a fresh organisation enrolment, a D-U-N-S request, and an app transfer. Reviews and ratings history does survive a transfer, but the wait is real calendar time. The second is an account enrolled under a previous freelancer's or agency's own entity, which makes the transfer dependent on cooperation from someone who has already moved on. Neither situation costs much in fees. Both cost weeks.

• • Apple Developer Program, organisation enrolment, in the client's legal entity name, 99 USD/year
• • D-U-N-S number requested for the exact legal entity name and address that appears on company registration documents
• • Google Play Console developer account, client entity, 25 USD one-time, plus the payments profile if the app will sell anything
• • App Store Connect roles: founder as Account Holder, agency leads as Admin or App Manager, QA as Developer, nobody as Account Holder except the founder
• • 2FA device and recovery email owned by the client, not by an individual engineer's phone
• • Apple Business Manager or a company Apple ID, so the account is not tied to one person's personal Apple ID
• • Push notification credentials created in the client account (APNs auth key for iOS, FCM service account for Android) and shared into the build, not created in an agency account

First-year cost lines for a from-scratch mobile build, in EUR

Excluding engineering time, the recurring and one-off platform cost of a first-year from-scratch React Native app typically lands between roughly 400 and 1,500 EUR, depending mostly on test devices and whether you buy error monitoring. The developer program fees are trivial. The lines that surprise founders are hardware and, later, backend usage.

Here is how the sheet is structured. Apple Developer Program is about 99 EUR a year at current exchange, Google Play Console is a one-off around 25 EUR. TestFlight and Google Play internal testing are both included with those fees, so beta distribution costs nothing extra. Firebase on the Blaze plan has a free usage allowance and for a pre-launch and early-launch app the monthly bill is frequently in single-digit euros, dominated by Firestore reads and Cloud Functions invocations rather than storage. Push notifications through FCM are free; APNs is included in the Apple fee. The genuinely variable lines are the QA device matrix and monitoring.

For the device matrix we buy or borrow four to six physical devices rather than relying on simulators: one current iPhone, one older iPhone still on a supported iOS version, one small-screen iPhone, one recent mid-range Android, and one budget Android from a manufacturer with aggressive battery management. Used devices are fine and that is where a few hundred euros goes. Anything past that matrix is cloud device testing rented by the hour when a specific crash report demands it. Error and performance monitoring is the one optional recurring line we argue for: Crashlytics is free and adequate at launch, and paying for a commercial tool is a decision better taken at month three when you know your crash volume.

• • Apple Developer Program: ~99 EUR/year, recurring, mandatory
• • Google Play Console: ~25 EUR one-off, mandatory
• • TestFlight + Google Play internal testing: 0 EUR, included
• • Firebase Blaze (Auth, Firestore, Functions, Storage, FCM): free tier plus usage, commonly single-digit to low-double-digit EUR/month pre-scale
• • Crashlytics + Google Analytics for Firebase: 0 EUR
• • QA device matrix: 300 to 900 EUR one-off for four to six used physical devices
• • Cloud device farm: rented ad hoc, tens of EUR per investigation, not a standing line
• • Domain + deep link hosting (universal links / app links): usually already covered by the marketing site
• • Optional: commercial error monitoring or session replay, 0 EUR at launch, revisit at month three

How we convert a screen count into weeks

We band every screen by complexity and apply a rough conversion: simple screens at roughly six to eight per engineer-week, medium screens at two to three, and complex screens at around one, then add a fixed overhead block for auth, navigation, state, offline handling, CI, and store submission. A 30-to-40-screen consumer app lands at 14 weeks with two engineers.

The bands matter more than the count. A simple screen is static or near-static content with no write path: an about page, a settings list, a terms screen. A medium screen has a form, validation, and a single write. A complex screen has real-time data, a list with pagination and optimistic updates, media handling, a map, or a payment flow. Founders count screens in Figma and see 40 boxes; the estimate is driven by the six of those boxes that are complex. On a typical consumer app the heavy screens are something like a schedule with booking state, a social feed, and a profile with activity history. Everything else is plumbing around them.

The fixed overhead is the part that cannot be compressed by cutting screens, and it is where the 14-week figure comes from rather than from the screens themselves. Roughly two weeks go to foundations (project setup, navigation, auth, design tokens, CI producing signed builds on both platforms), and roughly two to three weeks at the end go to hardening, device-matrix QA, store assets, submission, and the rejection turnaround. Cutting screens compresses the middle. It does not compress the ends. If a founder wants a faster date, the honest lever is cutting complex screens to medium ones, not cutting simple screens.

The six decisions a founder must make before any code is written

Six decisions are effectively irreversible once the app is live: bundle identifier and app name, auth provider, data residency region, offline-first or online-only, push provider, and in-app purchase versus external payment. Each one is cheap to decide in week one and expensive to change after the first public release. We date and record each in the decision register.

Bundle identifier is the hardest of the six because it is not reversible at all. The reverse-DNS identifier (com.yourcompany.yourapp) is permanent for a given App Store and Play listing. Pick it against the legal entity you will still own in five years, not against a product name you might rebrand, and register the matching identifier on both platforms on day one even if launch is months away. Auth provider is next: moving from email-and-password to a federated-only model, or off a managed provider entirely, means migrating user records and forcing a re-authentication event for everyone, which is a reliable way to lose part of an install base. Data residency sits in the same tier. Firestore's location is set at database creation and cannot be changed, so if your users or your DPA require EU residency, that choice is made before the first write.

The other three are reversible in theory and painful in practice. Offline-first changes your data layer shape, not just a caching setting; retrofitting it means introducing local write queues and conflict resolution into screens that assumed a network. Push provider decides whether your notification payloads, segmentation, and campaign history live somewhere you can leave, and moving providers invalidates saved device tokens. And in-app purchase versus external payment is a commercial and compliance decision, not a technical one: if the app sells digital goods consumed in the app, the platform rules point at in-app purchase, and building around an external processor first and discovering that during review costs a rejection cycle plus a rebuild of the entire payment path.

• • Bundle identifier and store app name: permanent, tied to the legal entity, registered on both platforms day one
• • Auth provider and identity model: email/password, federated, phone, or passwordless, and whether accounts can be merged later
• • Data residency region: set at database creation, driven by your DPA and user base, not by latency
• • Offline-first or online-only: a data-layer architecture choice, not a feature flag
• • Push provider: platform-native (APNs/FCM) versus a third-party layer, and who owns the device token store
• • In-app purchase versus external payment: check the platform rules against what you are actually selling before the payment path is built

What App Store rejection actually costs in days

Budget one rejection cycle into the launch window. Apple's published review turnaround is fast, with most submissions reviewed within 24 hours, but the real cost of a rejection is the fix plus the resubmission plus the rescheduled launch, which in our experience lands between two and five working days per cycle and occasionally more if the rejection is a policy question rather than a bug.

The rejections that cost the most are not code defects. They are missing account deletion paths, unclear sign-in-with-Apple requirements when other federated logins are offered, insufficient purpose strings on permission prompts, demo credentials that do not work for the reviewer, and app metadata that promises something the build does not do. Every one of those is preventable in week one by writing the requirement into the screen inventory instead of discovering it during submission. We keep a pre-submission checklist for exactly this reason, and the items on it were all added after one of them cost us days.

The operational consequence for a founder is simple: do not announce a launch date that equals your submission date. Announce against a window that includes one rejection cycle and a TestFlight round with real users. We structure the final weeks of a build as internal testing, external beta, submission, then buffer, and the buffer is what keeps a launch from slipping publicly.

If you want the calendar view of what happens after week one, we break it down week by week in the zero-to-App-Store timeline, including where the founder decision points actually fall.