The mobile app development process is not only a sequence of design, coding, testing, and launch tasks. For an EU company, it is also a sequence of business decisions. You decide what the app must achieve. You approve the brief. You confirm the platform direction. You review sprint outputs. You sign off on GDPR, security, and store submission details before the app reaches users. That client-side work is where many projects either stay controlled or start drifting. The dev team owns the code. The client owns the decisions that shape the code.
This guide explains what happens from brief to launch, what you as the client need to prepare, and where projects usually slow down. For deeper technical detail behind each stage, the Application Development Guide should act as the technical companion to this client-side process map.
TL;DR
A typical EU B2B mobile app takes 14 to 24 weeks from brief submission to App Store and Google Play launch. Lower-complexity internal tools may take 14 to 18 weeks. Customer-facing B2B apps with integrations and GDPR requirements often take 18 to 24 weeks. Apps with payments, marketplace logic, or complex user roles can take 24 to 36 weeks.
| Stage | Name | Typical timeline | What the client does |
|---|---|---|---|
| 1 | Brief and vendor selection | 1 to 3 weeks | Finalise the brief, compare proposals, appoint the internal project owner |
| 2 | Sprint 0 and project setup | 1 to 2 weeks | Approve architecture direction, Definition of Done, team rhythm, and compliance baseline |
| 3 | Build sprints for MVP | 6 to 12 weeks | Join sprint reviews, approve features, answer scope questions quickly |
| 4 | QA, security, and GDPR review | 2 to 4 weeks | Review test summary, security findings, privacy flows, and launch readiness |
| 5 | App Store submission and launch | 1 to 3 weeks | Approve store listing, privacy labels, release strategy, and monitoring setup |
| 6 | Post-launch monitoring and iteration | Ongoing | Track product metrics, approve version 1.1, and confirm support model |
The rule: the process works best when every stage ends with a documented approval. Verbal agreement is not enough once architecture, scope, GDPR, or launch timing is involved.
Why the process looks different for the client
Most mobile app projects do not fail because nobody can write code. They slow down because decisions arrive late. A vendor can plan a sprint only when priorities are clear. A QA team can validate a feature only when “done” is defined. A developer can build an integration only when API access is available. A compliance review can only confirm GDPR readiness when data flows are mapped.
This is the client-side view of delivery: The development partner designs and ships the product. The client protects the decision flow. That means you do not need to micromanage the team. You need to create the conditions for clear delivery: one product owner, documented approvals, fast answers, and a realistic launch buffer.
Stage 1: Brief and vendor selection, 1 to 3 weeks
Stage 1 turns an idea into a project that vendors can estimate. At this stage, the client prepares or refines the brief, collects proposals, compares delivery models, and signs the contract. A clear brief compresses this stage. A vague brief pushes uncertainty into Sprint 0 and build sprints.
If your team has not yet documented the product goal, user roles, features, integrations, and compliance assumptions, the mobile app development brief template should be used before final vendor comparison. It helps turn internal assumptions into something a development partner can estimate.
What happens at this stage
The vendor reviews the brief and asks clarification questions. Good vendors do not only quote the feature list. They test the assumptions behind the feature list. Look at the questions they ask:
- Do they ask about user roles and permissions?
- Do they ask where personal data will be stored?
- Do they ask what systems the app needs to integrate with?
- Do they ask what “launch-ready” means for your business?
- Do they ask who will approve sprint outputs?
A weak proposal gives a number too quickly. A useful proposal explains what must be decided before the number becomes reliable. For companies still comparing partners, the mobile app development company Europe checklist can sit next to this stage. The article should help readers compare vendors by architecture thinking, team structure, compliance readiness, and communication rhythm instead of day rate alone.
What the client does
The client should end Stage 1 with four things in place: a complete brief, a selected vendor, an internal project owner, and a contract model.
The contract model matters. A fixed-scope contract works when the MVP is stable and changes are controlled. Time-and-materials works when discovery will continue during delivery, but only if the backlog is actively managed.
Neither model protects the project by itself. The protection comes from how scope changes are approved.
Buyer action box
Before Stage 2 starts, confirm:
| Item | Owner | Done when |
|---|---|---|
| Brief is complete | Client | Scope, users, integrations, data, and launch goal are documented |
| Vendor is selected | Client | Proposal is approved beyond price |
| Contract is signed | Client and vendor | Scope model and change process are clear |
| Internal project owner is named | Client | One person can approve or reject sprint outputs |
| Access preparation begins | Client | APIs, test accounts, brand assets, and stakeholder contacts are identified |
Common risk
Signing a contract before the brief is complete creates scope disputes in Sprint 2 or Sprint 3. The dispute usually sounds like this: “We assumed that was included.” If the brief does not define the feature, the integration, the user role, or the acceptance condition, the vendor has to price uncertainty. That uncertainty becomes either budget buffer or change requests.
Stage 2: Sprint 0 and project setup, 1 to 2 weeks
Sprint 0 is where the project becomes buildable. For Sunbytes mobile app engagements, Sprint 0 is mandatory. It is the stage where architecture, communication rhythm, Definition of Done, compliance baseline, and launch responsibilities are agreed before Sprint 1 starts. Skipping Sprint 0 feels faster for about two weeks. Then the team starts finding gaps while writing production code.
What happens in Sprint 0
Sprint 0 should answer five questions.
| Sprint 0 question | Output |
|---|---|
| What are we building first? | MVP scope and backlog order |
| How will the app be built? | Architecture direction, platform choice, tech stack, integration map |
| What counts as done? | Definition of Done by feature type |
| How will we work together? | Sprint rhythm, timezone overlap, async update format, approval rules |
| What needs compliance review? | GDPR data map, DPA status, security testing scope, store submission requirements |
Platform choice belongs here, not halfway through build. If your team is still deciding between native, React Native, Flutter, or a platform-first release, the iOS vs Android build first guide and the React Native vs Flutter vs native comparison should support this decision before Sprint 1.
What the client approves
The client should review the Sprint 0 sign-off document, not only the backlog. That document should include:
| Approval area | What to check |
|---|---|
| Architecture direction | Platform, backend, hosting, API, third-party SDKs |
| Definition of Done | Acceptance rules for features, QA, security, performance |
| Team setup | Roles, communication channels, sprint review cadence |
| Compliance baseline | GDPR data flows, consent needs, DPA, access control |
| Launch checklist | Store accounts, listing ownership, monitoring, support window |
If the app handles personal data, GDPR review should start here. Article 32 of the GDPR requires controllers and processors to use technical and organisational measures appropriate to the processing risk, including measures such as encryption where relevant. That makes security and data handling part of the delivery baseline, not a launch-week task.
Buyer action box
Before Sprint 1 starts, approve:
| Item | Why it matters |
|---|---|
| MVP backlog | Prevents Sprint 1 from starting with unclear priorities |
| Architecture decision | Prevents rework once integrations and data flows are coded |
| Definition of Done | Gives QA and client reviewers the same acceptance standard |
| Communication rhythm | Protects delivery speed across remote teams |
| GDPR and security baseline | Prevents compliance discovery at the end of the build |
Common risk
Teams that skip Sprint 0 usually discover scope gaps in Sprint 3. By then, the project has working code, sprint commitments, and stakeholder expectations. Fixing a missing user role, wrong integration assumption, or unclear data flow at that point is more expensive than resolving it before Sprint 1.
Stage 3: Build sprints for the MVP, 6 to 12 weeks
Build sprints are where the MVP becomes visible. For the client, this is not the stage to disappear until the final demo. It is the stage to review working software in small increments, answer questions quickly, and protect scope from unplanned expansion.
A typical sprint rhythm includes planning, build work, async updates, review, and acceptance. The client does not need to join every technical discussion. The client does need to attend sprint reviews and make decisions. For EU teams working with a Vietnam delivery hub or another near/offshore partner, the remote mobile app development team management guide should sit naturally here. It can explain overlap windows, async updates, review rules, and how to avoid turning timezone difference into decision delay.
What happens in each sprint
Each sprint should produce visible progress. That may be a working feature, a tested user flow, a technical integration, or a design-to-build milestone. The client has four jobs during this phase:
| Sprint moment | Client role |
|---|---|
| Sprint planning | Confirm priorities and trade-offs |
| Mid-sprint update | Answer questions before they block the team |
| Sprint review | Test the working build, not just the demo |
| Feature acceptance | Accept, reject, or request changes with reasons |
The strongest client behaviour is fast, specific feedback. “This is not what we expected” is too late and too vague. “The approval flow works for admin users, but branch managers should only see their own region” is useful.
What good sprint participation looks like
Good sprint participation is structured, not heavy. The project owner should test the build on the target device, document feedback in the agreed tool, and separate defects from new ideas. A defect means the feature does not meet the Definition of Done. A new idea belongs in backlog prioritisation. This distinction protects budget. If every new idea is treated as a defect, the sprint loses control.
Buyer action box
During build sprints, the client should:
| Client action | Delivery impact |
|---|---|
| Attend sprint reviews | Prevents late surprise at QA stage |
| Test on real target devices | Finds usability and performance issues earlier |
| Answer questions within agreed SLA | Keeps developers unblocked |
| Separate bugs from new scope | Protects budget and sprint focus |
| Approve or reject features promptly | Prevents batch approvals at the end |
Common risk
Scope creep usually enters through “small” changes that are not logged. One extra field, one extra user role, one extra integration condition. Alone, each change looks harmless. Together, they change the product. The fix is not to block all change. The fix is to put every change through one visible decision route: accept into current sprint, move to next sprint, move to version 1.1, or reject.
By the end of Stage 3, the project has already made its most expensive decisions: architecture, scope, team rhythm, and acceptance rules. If your team wants those decisions mapped before Sprint 1, Sunbytes can walk through the process, risks, and approval points with your product owner before build starts.
Stage 4: QA, security testing, and GDPR review, 2 to 4 weeks
Stage 4 decides whether the app is ready for users, not only whether the features work. Functional QA checks whether the app behaves as defined. Security testing checks whether the app exposes unacceptable risk. GDPR review checks whether personal data is collected, processed, stored, and disclosed in the way the business has approved.
For EU companies, this stage cannot be treated as a final polish step. If the app handles personal data, GDPR and security evidence matter before launch. The mobile app security testing checklist should support the security part of this stage. The GDPR compliance for mobile apps guide should support the privacy and consent review without forcing this process article to repeat every legal detail.
What the client reviews
The client does not need raw test logs. The client needs a decision-ready summary. That summary should show:
| Review area | Client-facing output |
|---|---|
| Functional QA | Passed, failed, retest status by feature |
| Security testing | Findings ranked by severity and launch impact |
| GDPR review | Data flows, consent points, privacy policy, DPA status |
| Performance | Crash rate, load behaviour, device coverage |
| Release readiness | Open issues that block launch vs issues accepted for post-launch |
A finding is not automatically a launch blocker. The question is whether the risk is acceptable for launch, documented, and assigned to a fix timeline.
GDPR and security are linked
GDPR Article 32 does not prescribe one fixed security checklist for every app. It requires security measures appropriate to the risk of the processing. For a B2B app that stores personal data, that can include encryption, access control, logging, backup procedures, and incident response planning. That is why the client must understand the security summary, not only receive it. The business remains accountable for the risk it accepts.
Buyer action box
Before approving Stage 4 completion, review:
| Document | What to approve |
|---|---|
| QA summary | All MVP features are passed, rejected, or deferred |
| Security testing summary | Critical and high-risk findings are fixed or formally accepted |
| GDPR implementation summary | Data flows, consent, privacy policy, DPA, and user rights handling are ready |
| Launch issue list | Remaining issues are assigned to launch, post-launch, or version 1.1 |
| Monitoring plan | Crash reporting, analytics, and alerting are configured |
Common risk
Launching without a security test summary or GDPR consent review creates avoidable exposure. The problem is not only regulatory. It is operational. If a client, partner, or internal risk team asks for evidence two weeks after launch, the project team should not be reconstructing what was tested from Slack messages.
Stage 5: App Store submission and launch, 1 to 3 weeks
Store submission is where business, compliance, marketing, and technical delivery meet. The app may be built, tested, and approved, but it still needs to pass Apple and Google requirements. The client must approve the listing, privacy disclosures, age rating, screenshots, release strategy, and support plan. At Sunbytes, the App Store submission checklist is part of the standard Sprint 5 handover. That checklist prevents launch from depending on missing assets or unclear account ownership.
What the client prepares before submission
The client owns or approves several assets:
| Submission item | Client role |
|---|---|
| App name and subtitle | Approve wording and market positioning |
| App description | Confirm product claims and compliance wording |
| Screenshots and preview assets | Approve final store visuals |
| Privacy label or Data safety form | Confirm data collection and sharing declarations |
| Age rating and content declarations | Confirm accuracy |
| Release strategy | Choose hard launch, soft launch, phased rollout, or internal release |
| Support contact | Confirm user support route |
| Monitoring setup | Confirm crash reporting, analytics, and alerts |
Apple states that 90% of submissions are reviewed in less than 24 hours, but incomplete submissions can be delayed or rejected. Google Play uses standard publishing by default, but certain apps may go through extended review, including cases that take up to 7 days or longer. The practical planning rule: do not set a public launch date that assumes approval will happen on the first attempt.
Privacy labels and Data safety are not copywriting tasks
Apple’s privacy details require teams to know what data the app and third-party partners collect before answering App Store Connect questions. Apple also states that data must be declared even when it is collected for reasons other than analytics or advertising. Google Play’s Data safety section asks developers to provide information about app data collection and sharing through the Play Console. Google’s user-facing explanation says the Data safety section describes how apps collect, share, and handle different types of data. For the client, this means privacy disclosure is a product and legal responsibility. The vendor can prepare the form. The business must confirm the truth of the declarations.
Buyer action box
Before submission, approve:
| Item | Why it matters |
|---|---|
| Store listing content | Prevents inaccurate product claims |
| Screenshots and preview assets | Prevents visual mismatch with final build |
| Apple privacy label | Confirms data collection and partner SDK disclosures |
| Google Play Data safety form | Confirms data collection, sharing, and handling declarations |
| Release strategy | Controls user exposure and rollback options |
| Monitoring and support | Ensures the team can respond after release |
Common risk
A launch delay often comes from missing privacy details, incomplete store metadata, or unclear account access. These are not engineering delays. They are handover delays. The clean fix is to collect store requirements during Sprint 0 and complete the submission checklist before Stage 5 starts.
Stage 6: Post-launch monitoring and iteration planning
Launch is not the end of the process. It is the first test with real users. The first 30 days should answer three questions: is the app stable, are users completing the intended flows, and what must change in version 1.1? The client should not wait for a crisis to define the support model. A minimum 30-day support window should be agreed before launch, especially for customer-facing apps or apps with sensitive data.
What the client tracks after launch
Track metrics that connect to product health, not vanity numbers alone.
| Metric | What it tells you |
|---|---|
| Crash-free sessions | Whether the app is technically stable |
| Activation rate | Whether users complete the first intended action |
| Retention | Whether the app earns repeated use |
| Support tickets | Where users are blocked or confused |
| Feature usage | Which parts of the MVP matter in practice |
| Security or privacy issues | Whether post-launch risk needs immediate action |
If the product needs continuous iteration, the dedicated development team vs project-based outsourcing comparison can support the next decision. A fixed project may be enough for handover. A dedicated team makes more sense when the roadmap, integrations, and post-launch learning will continue.
Buyer action box
In the first 30 days, decide:
| Decision | Recommended timing |
|---|---|
| Which issues must be fixed immediately | First week |
| Which user feedback affects version 1.1 | Weeks 2 to 4 |
| Whether the current support model is enough | Week 2 |
| Which metrics define product success | Before launch, reviewed after 30 days |
| Whether the team continues or hands over | Before the support window ends |
Common risk
The most expensive post-launch mistake is discovering a critical bug or GDPR gap after the vendor has handed over and the team has dissolved. Define the support window in the contract. Keep the team available long enough to fix launch issues, review analytics, and hand over documentation properly.
How long does a mobile app take from brief to launch?
A realistic mobile app timeline depends on complexity, integrations, compliance scope, stakeholder speed, and platform strategy. For EU B2B companies, these ranges are practical planning baselines:
| App type | Typical scope | Timeline from brief to launch |
|---|---|---|
| Internal tool or B2B workflow app | 20 to 30 screens, controlled users, low integration complexity, no payment processing | 14 to 18 weeks |
| Customer-facing B2B mobile app | User accounts, integrations, GDPR flows, analytics, support setup | 18 to 24 weeks |
| Consumer app with payment or marketplace logic | Payments, multi-sided user roles, higher QA coverage, store risk, complex support model | 24 to 36 weeks |
The brief and vendor selection stage has the highest client-side variance. A complete brief can move Stage 1 toward one week. A weak brief can stretch vendor selection and push unanswered decisions into Sprint 0. The most useful timeline question is not “How fast can we build this?” It is “Which decisions must be made before speed becomes safe?”
What changes for Dutch companies working with a Vietnam delivery team?
For Dutch companies, the process does not need to become heavier because the delivery team is partly in Vietnam. It does need a stricter operating rhythm. The Netherlands-Vietnam setup works when decision flow is designed around overlap time. A 4 to 5 hour working overlap can be enough when sprint reviews, async updates, and approval rules are agreed in Sprint 0.
The risk is not distance. The risk is ambiguity. Dutch teams usually expect direct communication, clear ownership, and written agreements. A Vietnam delivery hub can support that well if the project uses:
| Operating rule | Why it matters |
|---|---|
| Fixed sprint review time | Prevents feedback from drifting across time zones |
| Written async update format | Keeps decisions visible without extra meetings |
| Named client project owner | Avoids approval loops across departments |
| 24-hour decision SLA for blockers | Protects sprint velocity |
| Definition of Done signed in Sprint 0 | Gives both teams the same acceptance standard |
| GDPR and DPA review before build | Keeps EU compliance in the delivery baseline |
For Dutch companies, AVG language may be used internally, but the legal basis remains GDPR. If the app handles personal data, privacy policy, consent flows, processor agreements, access control, and data retention should be discussed before launch week. This is also where vendor selection matters. The right partner should not only provide developers. They should provide the operating system around the developers: sprint rhythm, documentation, QA, compliance checkpoints, and launch handover.
How Sunbytes runs this process for EU clients
Sunbytes runs mobile app projects through a staged delivery process because most delivery risk appears at handoff points: brief to proposal, proposal to Sprint 0, Sprint 0 to build, build to QA, QA to launch, and launch to support. For mobile app engagements, Sprint 0 is mandatory. The team maps architecture direction, communication rhythm, Definition of Done, GDPR review points, and launch responsibilities before Sprint 1 starts. During Sprint 5, the App Store submission checklist is part of the standard handover so store access, privacy labels, listing assets, monitoring, and support responsibilities are not left to the final week.
Sunbytes is headquartered in the Netherlands with a delivery hub in Vietnam. The Transform Solutions are supported by dedicated senior delivery teams, ISO-guided delivery, and experience across 300+ projects. The Accelerate Solutions help put the right team structure in place. The Cybersecurity Solutions keep GDPR, access control, and security testing inside the delivery process instead of treating them as late-stage add-ons.
For EU companies planning a mobile app build, the next useful step is to map the first 90 days: brief quality, Sprint 0 decisions, MVP scope, QA evidence, and launch readiness. Plan your mobile app delivery process with Sunbytes
FAQs
Most EU B2B mobile apps take 14 to 24 weeks from brief submission to launch. Internal tools can take 14 to 18 weeks if scope is controlled. Customer-facing B2B apps with integrations and GDPR requirements often take 18 to 24 weeks. Apps with payments, marketplace logic, or complex user roles can take 24 to 36 weeks.
You need an approved brief, a named internal project owner, initial platform assumptions, access to relevant API documentation, and a starting view of personal data flows. Sprint 0 can refine the details, but it should not begin with an empty scope.
Small changes can usually move into the next sprint if they do not affect architecture, timeline, or dependencies. Larger changes should become a formal scope change with cost and timeline impact. The rule is simple: if a change affects another feature, another team, or launch readiness, document it.
Yes, the vendor can prepare and submit the app if the client grants the right App Store Connect and Google Play Console access. The client should still approve the listing, privacy labels, Data safety form, age rating, release strategy, and support contact before submission.
This article explains the client-side mobile app development process: what you approve, prepare, and decide at each stage. A technical application development guide explains the full delivery lifecycle in more depth, including architecture, development methods, testing, and deployment.
GDPR should start in Sprint 0, not during launch week. The team should map personal data, consent flows, third-party SDKs, DPA status, access control, and retention assumptions before build starts. Stage 4 then validates whether those decisions were implemented correctly.
Yes, but it can be lighter. A small MVP still needs scope, architecture, team rhythm, Definition of Done, and launch responsibilities. Without those decisions, the team may move fast in Sprint 1 and spend Sprint 3 fixing assumptions.
Let’s start with Sunbytes
Let us know your requirements for the team and we will contact you right away.
