Version 1 of a business app should ship one complete core job—not a brochure of every feature on the roadmap. If a new user cannot finish that job reliably, and the product does not clear the stores’ minimum utility bars, more screens usually make the launch worse, not better.
This article helps owners and operators decide what belongs in the first release, what can wait for proof, and what should stay out of the binary entirely—so budget goes into a usable product instead of a delayed wishlist.
Key takeaways
-
Define one core job for V1: the action a customer or employee must complete without leaving the app for a spreadsheet, phone call, or separate website flow.
-
Apple’s Guideline 4.2 and Google Play’s limited-functionality policy set a floor: thin website wrappers and static “info apps” are weak candidates for a first store release.
-
Every extra data field, SDK, and admin panel increases privacy paperwork, support load, and failure modes before you have usage evidence.
-
Use the V1 Scope Scorecard below. Score six dimensions, then place each candidate feature into Must-ship, Prove-later, or Out-of-scope.
Why V1 scope is a business decision
Most first-app delays are not engineering mysteries. They are scope failures: loyalty programs, chat, referral engines, multi-role dashboards, and marketing microsites get packed into the same release as the single workflow that actually justifies the install.
Store policy reinforces that discipline. Apple’s App Review Guidelines say an app should include features, content, and UI that elevate it beyond a repackaged website, and that apps which are not useful, unique, or “app-like” do not belong on the App Store. Guideline 4.2.2 adds that, other than catalogs, apps should not primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links. Google Play’s Functionality, Content, and User Experience policy likewise disallows apps with only limited functionality and content—for example static text or PDF-only apps, or apps designed to do nothing.
Those rules are not a substitute for product strategy, but they are a hard filter: if V1 is mostly a branded browser shell of your homepage, you are choosing a high-rejection, low-learning release. If you are still choosing native, cross-platform, or PWA distribution, settle that path first, then return here to cut the feature list.
The V1 Scope Scorecard
Score each dimension from 1 to 5 for the proposed first release as a whole. A 1 means the release cannot teach you whether the product works. A 5 means a stranger can complete the core job and the binary clears a credible utility floor. Maximum total: 30.
|
Dimension |
What a strong V1 looks like |
Score 1–5 |
|
1. Core job clarity |
One primary user can state the job in one sentence, start it within two taps of launch, and finish it without a second channel. |
___ |
|
2. Store utility floor |
The release is more than a marketing site or static content pack. It delivers lasting utility that justifies install and matches Android’s expectation of meaningful functionality. |
___ |
|
3. End-to-end completeness |
Happy path, empty states, errors, and “what happens next” are designed. Partial flows that dump users into email or phone support do not count as shipped. |
___ |
|
4. Support load realism |
Your team can answer tickets for every V1 feature without hiring overnight. High-touch admin tools and multi-role permissions usually fail this test early. |
___ |
|
5. Data liability budget |
Every collected field and third-party SDK can be explained in your privacy policy and store privacy disclosures. If you cannot inventory it, it does not belong in V1. |
___ |
|
6. Learning signal |
Within 30–60 days you can measure whether the core job is used, completed, and worth expanding. Vanity screens and unused settings produce noise, not signal. |
___ |
How to interpret the total
-
6–14: Do not build this as a store V1. Narrow to one job or keep users on a stronger mobile website until the score rises.
-
15–22: Shipable only after cutting features that drag completeness, support, or data liability. Typical cuts: social layers, multi-role admin, and marketing microsites.
-
23–30: A disciplined V1 is usually justified once device testing and privacy inventory are real, not aspirational.
Any single dimension scored 1 or 2 is a stop condition for that release plan, even if the total looks acceptable. A beautiful loyalty module cannot rescue an incomplete booking flow.
Sort every candidate feature into three buckets
After scoring the release, classify each proposed feature. The goal is not to reject good ideas—it is to sequence them after evidence exists.
|
Bucket |
Include when |
Defer or cut when |
|
Must-ship |
Required to complete the core job, meet the store utility floor, authenticate safely, or recover from common errors. |
Never defer authentication, confirmation states, or the final “job done” screen. |
|
Prove-later |
Likely valuable after people repeatedly finish the core job—push reminders, saved preferences, simple history, light personalization. |
If the feature needs new data types, new roles, or a second primary workflow, keep it out of V1. |
|
Out-of-scope |
Marketing microsites, social feeds, referral engines, heavy admin consoles, and “nice” screens that do not change job completion. |
These often recreate Guideline 4.2 risk or inflate support and privacy cost without teaching product-market fit. |
A practical cut rule
If a feature does not appear in the path from first open to first successful core-job completion, it is Prove-later or Out-of-scope by default. Exceptions are rare: legal consent screens, privacy policy access, account recovery, and crash-safe error handling.
What each scorecard dimension means in practice
1. Core job clarity
Write the job as a verb phrase tied to a business outcome: “book a service visit,” “reorder the last purchase,” “clock in and submit a job photo,” “approve a quote.” If stakeholders cannot agree on one phrase, you do not have a V1 yet—you have a portfolio.
2. Store utility floor
Apple’s 4.2 language and Google Play’s limited-functionality examples are your floor, not your ceiling. Android’s core app quality guidance also expects a consistent, navigable experience across the flows you claim to offer. For a business app, lasting utility usually means saved state, notifications that reopen a specific task, offline access to work data, camera or scanner intake, or another durable workflow that a mobile browser session handles poorly.
3. End-to-end completeness
A half-built feature is worse than an honest cut. If payments, confirmation emails, or staff notifications are part of the job, they belong in Must-ship or the job definition must shrink. Android quality guidance emphasizes consistent UX across use cases; incomplete paths that freeze, fail silently, or strand users are quality failures as well as product failures.
4. Support load realism
Count the human workflows behind each screen: password resets, booking changes, refunds, role permissions, content moderation. If V1 creates three new support queues your current team cannot staff, the scorecard should force a cut even when the mockups look ready.
5. Data liability budget
Apple requires developers to provide app privacy details in App Store Connect for new apps and updates, including practices of third-party partners whose code is integrated. Extra analytics, chat, or advertising SDKs are not “free”—they expand what you must disclose and maintain accurately. If a Prove-later feature needs new sensitive data types, leave it out until the core job proves itself.
6. Learning signal
Decide the one or two metrics that will tell you whether to expand: completed jobs per active user, time-to-completion, repeat use within 14 days, or support tickets per completed job. Features that cannot move those metrics belong later.
Worked example: multi-location clinic app wishlist
Consider a hypothetical multi-location clinic that wants a patient app. The first wishlist includes appointment booking, telehealth video, symptom chat, loyalty points, a blog reader, physician bios, referral sharing, and an admin console for front-desk staff.
A realistic scorecard on that full wishlist might look like this:
-
Core job clarity: 2 — stakeholders disagree whether booking or telehealth is primary
-
Store utility floor: 3 — booking could be app-like, but the blog and bios lean brochure
-
End-to-end completeness: 2 — telehealth and chat are sketched without staffing or escalation paths
-
Support load realism: 1 — chat plus admin console exceeds current front-desk capacity
-
Data liability budget: 2 — health-adjacent chat and video expand disclosure and process needs before readiness
-
Learning signal: 2 — too many surfaces to learn which job patients actually need
Total: 12 / 30. Under the bands, this should not ship as one V1.
A tighter plan picks one core job—“book, reschedule, and get reminders for an in-clinic visit”—and re-buckets the wishlist:
-
Must-ship: account login, location selection, book/reschedule, confirmation, reminder opt-in, support contact, privacy policy access
-
Prove-later: visit history, saved preferences, push deep links to a specific appointment
-
Out-of-scope for V1: telehealth, symptom chat, loyalty, blog reader, referral engine, full admin console (use existing web tools)
That narrowed release can re-score into the mid-20s because completeness, support, and learning become measurable. Telehealth can return as V2 only after booking completion rates and no-show data justify the added operational load.
Common failure patterns
-
Brochure inflation: V1 becomes a mobile website with an icon—high Guideline 4.2 risk and low learning.
-
Two products in one binary: customer journey and staff admin share the first release, doubling roles, permissions, and support.
-
SDK tourism: analytics, chat, and ads land before the core job is stable, expanding privacy disclosures without product proof.
-
Partial job shipping: users can start a flow but cannot finish without calling the office—measured as “engagement,” experienced as failure.
-
Roadmap guilt: stakeholders keep features “just in case,” then wonder why the timeline and budget moved.
Limitations and exceptions
This scorecard is a prioritization aid, not a promise of store approval or product-market fit. Category rules for health, finance, kids, and other regulated verticals can add requirements beyond the six dimensions.
Internal-only apps distributed outside the public stores follow different operational paths. Even then, core-job clarity and support realism still matter; only the store utility floor changes weight.
If demand is unproven, a strong mobile website may be the better first channel. An app becomes the higher-leverage V1 when retention, push, device capabilities, or store distribution are part of how the business wins—not merely because competitors show an icon.
Recommended next steps
-
Write the one-sentence core job and list every screen required to finish it. Everything else starts in Prove-later or Out-of-scope.
-
Score the six dimensions with one product owner and one operator who will answer support tickets. Resolve disagreements with a clickable prototype, not a slide deck.
-
Inventory data types and SDKs for the Must-ship set only. If disclosure or policy work is unclear, cut the feature before engineering spends the budget.
-
Define the 30–60 day learning metrics before build starts. If you cannot name them, the scope is still too wide.
-
Only after the scoreboard clears 23—or a deliberate 15–22 plan with named cuts—move into build and later store-readiness checks.
If you need a team that can turn a crowded wishlist into a shippable first release—and then take it through iOS and Android delivery—Oasbit’s mobile app development services cover native and cross-platform builds with matching APIs and launch support. For distribution-path decisions before scope locks, see Native, Cross-Platform, or PWA: Choosing Your First Mobile Path. When the binary is near review, use What to Check Before Submitting Your First Business App to the Stores.
When your scorecard shows a wishlist that still cannot pick one core job, book a growth strategy session and bring the feature list, support capacity, and privacy policy draft. We will help you decide what belongs in V1, what waits for proof, and what should stay on the website.
Sources
-
App Store Review Guidelines — Apple Developer (Guideline 4.2 Minimum Functionality, including 4.2.2)
-
Functionality, Content, and User Experience — Play Console Help (limited functionality and content)
-
Core app quality guidelines — Android Developers
-
App privacy details on the App Store — Apple Developer
