INPUT FEATURE: A mobile app for our web-based invoicing tool DEMAND: Roughly 8 of 200 paying customers asked in the last 6 months, mostly in support chats PRODUCT: A responsive web app for freelancers to send invoices and track payments. Most users log in 2-3 times a month, usually from a laptop. COST: About 3 months of our only developer, plus app store maintenance OUTPUT (Claude Sonnet, unedited) ## Verdict **NOT NOW** — 4% of customers mentioning something in support chats, with no purchase or churn signal behind it, isn't enough evidence to justify three months of your only developer's time. ## What problem this actually solves The underlying job is likely "let me check invoice status or payments when I'm not at my laptop" (assumed — the actual job wasn't stated, only the requested solution). A cheaper solution to the same job is a better mobile-optimized web experience (you already have a responsive web app) plus optional push notifications, which needs no app store presence at all. ## Evidence check | Signal | What I have | Strength | |---|---|---| | Who asked | 8 of 200 paying customers | Weak | | How often | Over 6 months, via support chats (not a dedicated feature request channel) | Weak | | What they do today instead | Log in 2-3x/month, usually from a laptop | Weak (suggests low urgency) | | Paid or churned over it | Not mentioned | Missing | | Usage data support | No mobile-browser session data given | Missing | ## The cheapest test Over 5 working days: email all 200 customers (and show a banner in-app) linking to a "Invoicing app for your phone — coming soon" landing page with a "Notify me" button (a fake door). In parallel, pull existing server logs for the % of sessions already coming from mobile browsers over the same period. - Measure: click/signup rate on the fake door, and current mobile-web session share. - Go if: over 15% of customers click "Notify me," OR mobile-web sessions already exceed ~20% of total. - Stop if: below that — the 8 vocal customers aren't representative. ## If you build it Smallest version: a installable mobile-web (PWA) experience with push notifications for "payment received" and "invoice viewed," not a native app. Leave out: invoice creation/editing on mobile, offline mode, and any native app-store listing beyond the PWA install prompt. Metric at 30 days: weekly active mobile users as a % of total weekly active users — if it's under 5%, the demand wasn't real. ## The cost of yes This is 3 months of your only engineer — effectively your entire near-term roadmap capacity (assumed: no other engineers to cover it). It displaces whatever else was next in line, which for a payments tool is plausibly reliability, integrations, or reporting work with broader reach. Permanent maintenance: OS version churn, app store review cycles, and a second codebase to keep in sync with the web app, indefinitely — carried by the same one developer with no backup. ## Kill criteria - If the 5-day fake-door test (running by 2026-09-19) gets under 10% click-through and mobile-web sessions stay under 15% of total, do not build — revisit only if that pattern changes. - If built anyway, and by 2026-11-15 (30 days post-launch) weekly mobile active users are under 5% of total active users, sunset the app rather than keep maintaining it. - If the single developer is reassigned or leaves before app store approval is complete, halt the project — do not let it become permanent half-finished maintenance debt.