app-decision-framework.md lives in your project’s docs/decisions directory.
This file tracks your choice between building a mobile native app or a progressive web app as your first public launch, so you avoid scope creep and align your build with your target user needs. No assumptions are included that are not tied directly to your documented launch constraints, target persona, and 12-week launch timeline.
Core decision criteria for this file
Every entry in this file ties back to four non-negotiable criteria you outlined in your project kickoff notes, so you avoid getting distracted by shiny features or irrelevant third-party advice. First, user reach: you need to maximize the number of potential early adopters who can access your tool without unnecessary friction, as you have no paid marketing budget reserved for driving app downloads. Second, build time for MVP: you need to launch in time to demo your tool at your industry’s annual creative conference in 12 weeks, where you will pitch to 200+ potential partner brands and early power users. Third, core feature access: your tool’s core value proposition relies on the ability for users to upload photos of their work directly from their device camera, tag projects with location data, and receive real-time alerts when clients send feedback. Fourth, post-launch maintenance lift: as a solo founder with no dedicated engineering team, you need to keep monthly maintenance work to a minimum so you can prioritize user acquisition and feature iteration for the first six months post-launch. No changes to these criteria are added to this file without a formal note explaining the shift in constraints.
Tradeoff breakdowns in this file
The table below breaks down how mobile native and progressive web builds perform against each of your core criteria, with data sourced from 2024 cross-platform development benchmarks and user behavior studies.
| Criterion | Mobile Native App | Progressive Web App |
|---|---|---|
| User reach | Requires approval from Apple App Store and Google Play Store, limits access to users who intentionally download the app, 30% of casual users abandon download flows if they require account creation pre-install | Accessible via any mobile or desktop browser, no download required, users can access the tool in 2 clicks from a social media ad or search result |
| Build time for MVP | 10–14 weeks for cross-platform build with React Native or Flutter, plus 1–2 weeks of back-and-forth for app store approval | 6–9 weeks for full MVP with responsive design, no approval process required to launch |
| Core feature access | Full access to device hardware (camera, GPS, push notifications, offline storage) out of the box, no workarounds required for most use cases | Limited access to background processing and advanced hardware features, push notification support is inconsistent across iOS browsers as of 2024, offline functionality requires custom service worker configuration |
| Post-launch maintenance lift | 10–15 hours of work per month for OS update patches, app store guideline compliance checks, and cross-platform bug fixes | 3–7 hours of work per month for browser compatibility updates and performance tweaks, no third-party platform approval required for feature pushes |
Illustrative example: 68% of your target user base (freelance creative workers) report they need to access project management tools offline when working on location with no cell service, a use case that is far simpler to support with a native mobile build. If your core value prop relies on offline access or reliable push notifications to drive engagement, the mobile app is worth the extra build time. If your top priority is getting in front of as many users as possible as fast as possible to test product-market fit, the web app is the clear choice. You can pull pre-built authentication and payment processing modules for either build type from the Build Next Stack component library to cut 2–3 weeks of development time regardless of your choice. If your survey finds that most of your users only access the tool from their desktop computers when working from home, the web app is the obvious choice, as you don’t need advanced mobile hardware features, and you can launch 4 weeks earlier to test demand. If your survey finds that users want to receive real-time push notifications when a client sends a new request, you may need to prioritize the mobile app, as iOS Safari still does not support reliable push notifications for web apps as of 2024, and workarounds tend to have a 40% lower opt-in rate than native push notifications.
Actionable next steps in this file
All edits to this file before your next session follow these four steps, so you keep the decision framework consistent and easy to reference for future contributors. First, fill in the user research data section at the top of this file with your actual user survey results, replacing the illustrative example above with real data from your 200-person beta sign-up list. You can pull the survey results directly from your Typeform account, and filter out responses from users who do not fit your target persona of freelance creatives with 1–5 years of experience. Second, mark the criterion that is non-negotiable for your launch with a [PRIORITY] tag next to it in the table above. If you have multiple non-negotiable criteria, rank them in order of priority, so you can weigh tradeoffs more easily. Third, add a 1-sentence note below the table justifying your choice, so all future contributors understand the reasoning behind the call. This justification will be critical if you revisit this decision 6 months post-launch, as it will help you remember what constraints you were working with during the initial build phase. Fourth, tag your lead developer in a comment on this file to get their sign-off on your estimated timeline before you lock in the build path. Your lead developer can flag any unforeseen challenges with your chosen build path, such as unexpected costs for cross-platform development tools or compatibility issues with older operating systems.
Next edit session for this file
You open this file 3 days from now, once you have compiled all user survey responses from your beta list. You cross-reference the priority criteria you marked earlier with the actual user needs you uncover, and finalize your build choice. If you choose the web app, you add a link to the web app MVP roadmap in the section below this heading, and note the extra $20 per month for a high-performance hosting plan that can support 10,000+ monthly active users without performance drops. If you choose the mobile app, you add a link to the app store pre-launch checklist and cross-platform build plan here, and note the extra $120 per year for Apple Developer Program and Google Play Developer membership fees to add to your operating budget. You also add any notes from your developer sign-off to the bottom of the file, so you have a single source of truth for the decision moving forward. You do not make changes to the core tradeoff table unless you uncover a new non-negotiable criterion that you did not account for during your initial kickoff. Before you close the file at the end of this session, you add a date for your next decision check-in, 3 months post-launch, when you will revisit this file to see if your initial choice is still aligned with your user needs and business goals. You also add a direct link to your launch timeline spreadsheet, so anyone referencing this decision in the future can see exactly what timeline constraints you were working with when you made the call.