Is building a mobile app still worth it for a solo developer?

Executive Summary & Verdict

Risky — 5/10. Build it, but change what you expect from it and change how you plan to reach people. The product idea is genuinely good and genuinely defensible; the go-to-market in these answers is not a plan, it is a hope that the App Store will find your customers for you.

Three findings drive the score. First, the economics of the funnel: at a $29.99 annual price and a 15% platform commission you net $25.49 per subscriber in year one, while the cheapest published US install costs imply roughly $93 to $197 of paid spend per paying subscriber [1]. That gap cannot be closed by better creative or a smarter bid strategy. Second, the base rates: across RevenueCat's subscription-app dataset, 17.3% of apps reach $1,000 a month and 4.6% reach $10,000 a month within their first two years, and the cross-category median one year after launch is around $72 a month [2]. Your stated goal puts you in the top sixth of all subscription apps. Third, and in your favour: the capital at risk is small, the fixed costs are trivial, and you keep your salary throughout. A bad outcome here costs you a few thousand dollars and a year of evenings, not your house.

What makes this a 5 rather than a 3 is that you own the asset most app founders lack: real, specific, hard-to-copy domain knowledge. What makes it a 5 rather than a 7 is that you have no audience, no marketing experience and no budget to buy either. Section 07 sets out the sequence that gives the knowledge a chance to matter — build the audience before the paywall.

Idea Validation

The premise is sound and it passes the test most app ideas fail. You are not building a better weather app; you are building an answer. "Can I launch at Fort De Soto's north ramp on Saturday morning?" is a question with a yes or a no, and the people who ask it currently answer it by cross-referencing three free apps and a Facebook group. Replacing four minutes of interpretation with one screen is a real job to be done.

The differentiator is the strongest line in your answers, and it is strong precisely because it does not scale. Forty-three named launches with encoded local behaviour is not a dataset anyone can buy; it is something you know because you have been stuck on a mud flat. That is a durable moat against a well-funded competitor, and it is also the reason the addressable market is small. Those two facts are the same fact.

What is missing from the answers is any evidence that this audience pays for apps. Kayak anglers are, as a group, price-sensitive, resourceful and already served by free tools that are 70% as good. The question is not whether your app is better — it plainly is — but whether "better than free, for something I do four times a month" clears $29.99 a year. That is answerable before you write the paywall, and section 07 tells you how. Do not treat it as self-evident. It is the assumption the whole plan stands on.

Market & Target Customer

Your market is not "kayak fishing in America". It is the number of people who (a) kayak fish on the Florida Gulf Coast often enough to care about launch conditions, (b) would think to look for an app rather than ask a Facebook group, and (c) will pay for it. Each filter cuts the number by more than you expect, and the third is brutal.

The distribution problem follows directly. App Store discovery is overwhelmingly search-driven: Sensor Tower's study of download sources found 65% of App Store downloads came from search, rising to 69% for non-game apps [1]. That figure is from 2017–18 and browse has grown since, but the shape has not changed — if nobody searches for what you built, the store will not surface it. And nobody searches "kayak launch conditions Tampa Bay" in meaningful volume. The high-volume queries in your space are "tides", "fishing", "wind" and "weather", and you will never rank for those against incumbents with millions of installs.

What to measure before you commit the build hours

• Membership counts in the three or four largest Florida kayak fishing Facebook groups and forums. These are your total realistic reachable audience in year one, and you can count them this afternoon.
• Entry lists for the Gulf Coast kayak tournament series. Tournament anglers are the segment most likely to pay, and they are enumerable by name.
• Search suggestion volume for your candidate keywords in App Store Connect and Play Console. Read the actual numbers, not an ASO blog's estimate.
• How many people in those groups already pay for a marine subscription of any kind. Ask in a post. Twenty honest answers beats a market report.

The uncomfortable arithmetic: if the reachable Florida audience is 40,000 people and you convert an extraordinary 1% to paid, that is 400 subscribers and about $850 a month net — roughly your stated goal, reached only at a conversion rate almost nobody achieves and against an audience you would have to reach in full. Plan for geographic expansion from day one, or plan for a smaller number.

Competitive Landscape

You have three tiers of competitor and only one of them is another app.

Tier one is free and good enough. The national marine forecast apps, the tide tables your customers already have bookmarked, and the NOAA data feeds they can read directly. These are not going to be beaten on data quality, coverage or price. They are beaten only on interpretation, which is your whole pitch — so make sure the app never, ever presents raw numbers as its main screen. The moment it looks like a data app it is competing with free.

Tier two is the Facebook group. A post asking "anyone launched at Weedon Island this week?" gets five answers in twenty minutes, from named people, for nothing. This is your real competitor and it is genuinely better than software in one respect: it is social. You cannot beat it on accuracy or cost. You can beat it on speed at 4.30am on a Saturday, which is exactly when the question gets asked and exactly when nobody answers.

Tier three is the well-funded app that copies you. Apple's own guidelines prohibit copycats — "Don't simply copy the latest popular app on the App Store, or make some minor changes to another app's name or UI and pass it off as your own" [1] — but that rule catches clones, not a large competitor adding a launch-conditions feature. Your defence is not legal, it is the 43 launches. Keep adding them. A competitor can build your UI in a sprint and cannot build your local knowledge at all.

Business Model & Monetisation

A subscription is the right instrument for this product — conditions change daily, so the value is recurring rather than one-off, and Apple's subscription rules require exactly that ongoing value. But you should understand what the platforms take before you model anything.

On the App Store you qualify for the Small Business Program at a 15% commission, available to developers who earned no more than $1 million in proceeds in the prior calendar year and no more than $1 million in the current year [1]. You will not be troubling that ceiling. On Google Play, for the US, auto-renewing subscriptions are charged at 10% plus a 5% billing fee under the fee structure that took effect on 30 June 2026 [2]. So plan on 15% on both stores and net 85% of the sticker price. That is a far better deal than the 30% that dominates the folklore, and it is one of the few things in this plan that is better than you probably assumed.

Revenue lines, in the order they are likely to matter

• Annual subscriptions. Better cash and better retention economics. Push these hardest on the paywall; most of your revenue comes from here or nowhere.
• Monthly subscriptions. A low-commitment option for seasonal anglers. Expect worse retention and treat the monthly price mainly as a device to make the annual look cheap.
• A tournament or club licence. Twenty seats sold to a tournament series organiser in one conversation beats two months of organic installs, and the buyer has a budget and a reason. This is the line your answers do not mention and the one most likely to pay.
• Not advertising. At your plausible audience size ad revenue would be a few dollars a month, and it drags in the whole App Tracking Transparency and Data safety burden in section 14 for nothing.

Finances & Budget

This is the section that produces the verdict, and it splits cleanly in two: the cash budget is comfortable, and the funnel arithmetic is not.

The cash budget, 18 months to launch and first year of operation

Against $9,000 of savings, that leaves $1,507. A 20% contingency would be $1,499 and six months of post-launch run cost is about $640, so your budget funds one of those two comfortably and both of them only just. That is a tighter position than it looks but it is not the thing that breaks this plan.

The funnel arithmetic, which is

Work it forward from the goal. $1,000/month net is $12,000 a year net. At $29.99 annually less 15% commission you net $25.49 per subscriber, so you need 471 active paying subscribers.

Now the conversion. You have chosen a hard paywall with a seven-day trial, which is the right choice: RevenueCat's 2026 benchmarks put median day-35 trial-to-paid conversion at 10.7% for hard paywalls against 2.1% for freemium, roughly five times better [3]. But a hard paywall also means not every installer starts a trial. Assume a generous 25% of installs start one. That gives an install-to-paid rate of 0.25 × 10.7% = 2.7%, and 471 ÷ 0.027 ≈ 17,600 downloads to stand up 471 subscribers.

Then churn. The same dataset reports that roughly 72% of annual subscribers cancel within year one, with 35% of all annual cancellations landing in month one [3]. So holding 471 means replacing about 340 subscribers a year, which is another 12,700 downloads every year, forever, just to stay level.

Finally the cost of buying those downloads. Published US cost-per-install figures run $2.50 to $5.00, with North America averaging $5.28 in 2024 [4]. At a 2.7% install-to-paid rate that is $93 to $197 of ad spend per paying subscriber against a $25.49 first-year net. RevenueCat's median realized lifetime value per payer after twelve months ranges from $11.22 in Gaming to $35.64 in Health & Fitness [5] — even the top of that range is a third of the cheapest install cost per paying subscriber. Paid user acquisition is not expensive for you. It is arithmetically closed.

MVP & What to Build First

The sequencing question for this plan is not which features to cut. It is whether the first thing you build is software at all. Given that paid acquisition is closed and App Store search volume in your niche is negligible, the audience is the harder half of the problem, so build it first and build it in public.

Weeks 1–8: publish the knowledge, not the app

Write up the 43 launches as a free, ugly, fast website — one page per ramp, tide stage, wind exposure, parking, what closes it. No signup, no app, no paywall. Post each one into the Facebook groups and forums you counted in section 03. This costs you almost nothing, it is the same content the app will encode, and it answers the only question that matters: do these people want this badly enough to come back? An email list of 500 kayak anglers who found that site useful is worth more than $1,500 of ads and is the only distribution you will ever have.

Weeks 9–26: the narrowest app that is still allowed

Then build for iOS only, for eight launches, in one county. Be careful here, because Apple's minimum-functionality bar is real and it is where thin solo apps die: guideline 4.2 states that an app "should include features, content, and UI that elevate it beyond a repackaged website" and that if it "is not particularly useful, unique, or 'app-like,' it doesn't belong on the App Store" [1]. A screen that renders your web tables will be rejected. What clears the bar is the thing a website cannot do: local notifications the night before a good window, offline access at a ramp with no signal, and a saved-launches list tied to the device. Build those three and nothing else.

What to defer, deliberately

• Android, until iOS has paying users. Not for revenue reasons but for time: Google Play requires new personal developer accounts to run a closed test with at least 12 testers opted in continuously for 14 days before applying for production access [2]. That is a scheduling dependency, not a formality.
• Accounts and sync. Every account is an in-app account-deletion obligation under Apple's rules — see section 11 — plus a privacy declaration and a support burden.
• The other 35 launches. Eight ramps done properly proves the concept; forty-three done shallowly proves nothing and takes four times as long.
• Any social feature. You cannot beat the Facebook group at being the Facebook group, and a report-a-condition feed is user-generated content with moderation attached.

Go-to-Market & Launch Plan

You get one launch and the App Store will not give you one. Launch to the list you built in section 07, on a date that matters to your customers, and treat the store as a payment processor rather than a channel.

• Launch on the eve of a season, not on a Tuesday. The week before the Gulf Coast kayak tournament series opens is the one week a year your customers are actively thinking about launch conditions. That timing is worth more than any keyword.
• Give the tournament organisers the app for free, by name, before launch. Twenty visible anglers using it is your entire credibility strategy and it costs you nothing.
• Submit for review three weeks before your date. Apple requires submissions to be "final versions with all necessary metadata and fully functional URLs included" with placeholder content removed [1], and a new developer's first submission frequently comes back. Plan for two rejections, not zero.
• Do not launch on both stores at once. The Play closed-test requirement [2] alone will desynchronise you, and debugging two launches in one week on twelve hours of availability is how solo launches fail.
• Ask for reviews in the app, at the right moment — not on second open, but after a trip the app said would be good. Review count is one of the few store-side levers you control.

The thing not to do is buy a launch. $1,500 at even the optimistic $2.50 CPI is 600 installs, which at your funnel rates is about sixteen paying subscribers and $408 a year of net revenue [3]. The same $1,500 spent sponsoring a tournament's prize table puts your name in front of every entrant and gets you introduced from the stage.

Marketing & Growth

For an app in a niche this narrow, the entire marketing question is: where do these people already gather, and what can you give them that is worth their attention? Everything else is noise you cannot afford.

The structural problem, stated plainly. Consumer app distribution has two doors. One is paid, and at $2.50–$5.00 per install [1] against a $25.49 first-year net it is closed to you — not marginal, closed. The other is search, and two-thirds of App Store downloads do come from search [2], but the searches that reach you do not exist in volume. There is no third door that a $1,500 budget opens. The only thing that works at your scale is owned audience: a list, a following, or somebody else's audience lent to you.

The four things worth your hours

• The free launch guide site. It is content marketing that happens to also be your product research, it ranks in Google where the long-tail queries actually exist, and it is the only asset you own outright.
• Two or three YouTube kayak fishing channels. Regional creators with 30,000 to 200,000 subscribers are reachable by email, cheap or free, and speak to your exact customer. One integration is worth more than every paid channel available to you.
• Onboarding and the trial, relentlessly. 55% of trial cancellations happen on day zero [3], so most of your conversion is decided in the first ninety seconds. Fixing that costs nothing and moves the only number that matters.
• Winning back annual lapsers. Month one is 35% of all annual cancellations [3]. A personal email at day 20 of the renewal cycle is your highest-return marketing activity.

What to skip: paid social, Apple Search Ads on head terms, an Instagram content calendar, a press push, Product Hunt. None of them reach a kayak angler in Cedar Key.

Pricing Strategy

Your prices are too low, and the reason is that you priced against free apps rather than against the cost of a wasted Saturday. A kayak angler spends $60 on gas, bait and ice for a trip and $1,200 on the kayak. $29.99 a year to not waste one of those trips is not a hard sell; $29.99 a year framed as "cheaper than the other tide apps" is.

• Raise the annual to $39.99 and hold the monthly at $4.99. The ratio matters more than the absolute: at $4.99 monthly the annual has to look like a clear saving, and $39.99 against $59.88 does that while $29.99 leaves money on the table. Test it — the paywall is the cheapest experiment you will ever run.
• Keep the seven-day trial, and know the rule. Apple requires an auto-renewable subscription to "provide ongoing value to the customer" with a period of "at least seven days", available across all of the user's devices [1]. A daily forecast clears "ongoing value" without argument; a static launch database would not.
• Longer trials convert better. RevenueCat reports 17–32 day trials converting at 42.5% against 25.5% for trials under four days [2]. A 14-day trial spanning two weekends is worth testing against seven, because a kayak angler cannot evaluate your app without a trip.
• Consider a one-off unlock alongside the subscription. A $59.99 lifetime tier catches the substantial group who will never subscribe to anything, and Apple permits a non-subscription time-based trial via a Price Tier 0 non-consumable named "XX-day Trial" if you go that route [1].
• Never discount into the store. An introductory offer trains the niche to wait, and at 471 subscribers you cannot afford a cohort that renews at a lower price.

One thing not to do: set the price by what feels fair for the work. Price by what a wasted trip costs, and fix the conversion rate with better onboarding rather than a lower number.

Legal Setup & IP

For a solo app developer in the US, the binding legal regime is not statute — it is the two platform contracts, which can remove your product with no appeal worth the name. Read them as the operating law of your business.

The platform rules that actually reject solo apps

• Minimum functionality, guideline 4.2. Your app "should include features, content, and UI that elevate it beyond a repackaged website", and if it "is not particularly useful, unique, or 'app-like,' it doesn't belong on the App Store" [1]. This is the single most common reason a thin first app from a solo developer is rejected. Guideline 4.2.2 adds that apps must not primarily be "marketing materials, advertisements, web clippings, content aggregators, or a collection of links", and 4.2.3 requires the app to "work on its own without requiring installation of another app to function" [1].
• Account deletion, guideline 5.1.1(v). "If your app supports account creation, you must also offer account deletion within the app" [1]. In-app, not by emailing support. The same guideline says that if your app "doesn't include significant account-based features, let people use it without a login" — which for you is an argument for having no accounts at all in v1.
• In-app purchase is mandatory for unlocking features, guideline 3.1.1. "You must use in-app purchase. Apps may not use their own mechanisms to unlock content or functionality, such as license keys" [1]. Note separately that the guidelines currently state external purchase link entitlements "are not required for developers to include buttons, external links, or other calls to action in their United States storefront apps" [1] — the US position here has moved repeatedly through litigation, so confirm the current rule and the applicable fee before you build any web checkout.
• Subscription rules, guideline 3.1.2(a). Ongoing value, minimum seven-day period, available across all the user's devices [1].
• Play Store production access. A closed test with 12 testers over 14 continuous days before you can apply to publish [2].

Structure, liability and IP

• Structure. A sole proprietorship is the cheapest start and is what your answers assume. An app that tells people whether it is safe to launch a kayak is giving advice about a physical activity with a drowning risk, and that is a real argument for a Florida LLC and for taking the advice seriously rather than defaulting. Ask a Florida attorney this specific question before launch.
• Your terms must disclaim reliance, prominently and in the product. Not buried in a policy — on the forecast screen. "Conditions can change; you are responsible for your own safety decision" is both honest and the sentence you will be glad you wrote.
• Data licence terms. Read what your marine forecast provider permits. Many commercial weather APIs restrict redistribution, resale or use in a paid product, and discovering that after launch is a business-ending problem, not an inconvenience.
• IP. The 43 launches are your asset. Your own compiled descriptions are copyrightable; the underlying tide facts are not. Check the USPTO register before you pay for an icon or a name, and secure the domain and handles the same week.

Tax, Invoicing & Admin

There is one genuinely good piece of news here and it is worth stating accurately, because a lot of app-developer advice gets it wrong: you almost certainly do not have to deal with US sales tax on app sales.

Nearly all sales-tax states have adopted marketplace facilitator laws, which "impose an obligation on the platform that facilitates the sale to collect and remit sales tax on behalf of the marketplace seller" [1]. Google states this outright: "Google is responsible for determining, charging, and remitting sales tax for Google Play Store app and in-app purchases by customers in these states using Google Play's billing system", covering all fifty states, and "you don't need to calculate and send sales tax separately for customers in these states" [2]. Apple's own tax guidance assigns the developer responsibility for determining, charging and remitting tax only "for purchases made using alternative payment options" [3] — which is the mirror image of the same arrangement. Two consequences follow. First, do not register for sales tax in fifty states; you are not the seller of record. Second, if you ever sell the same subscription directly from your own website, that protection disappears and the obligation is yours — which is a hidden cost of the "avoid the 15%" strategy that nobody mentions.

What you do owe

• Schedule C. "Use Schedule C (Form 1040) to report income or loss from a business you operated or a profession you practiced as a sole proprietor" [4]. Your app revenue and every line in the section 06 table lives here.
• Self-employment tax at 15.3% — 12.4% Social Security plus 2.9% Medicare — and you must file Schedule SE once net earnings from self-employment reach $400 or more [5]. This is the tax that surprises salaried engineers: your employer normally pays half of it and here nobody does.
• Quarterly estimated payments if you expect to owe $1,000 or more when the return is filed [6]. With a salary alongside, one option is increasing withholding at the day job instead; ask your CPA which is cleaner for you.
• Foreign withholding and VAT you will never see. Both stores withhold or remit consumption taxes in dozens of territories before you are paid. Your payout report is your revenue record, not your gross sales — reconcile from the platform reports, not from your own subscriber count.
• Records from day one. Separate bank account, the two platform payout reports, and receipts for the $99, the $25, the API and the hosting. All of it is deductible and all of it is easier to keep than to reconstruct.

Tech, Hosting & Security

You are a backend engineer, so the temptation here is to build the interesting version. The correct version is boring, cheap and almost stateless.

• Do not store user data you do not need. This is the single highest-leverage technical decision in the plan, because it collapses most of section 14. No accounts, no server-side location history, no device identifiers — and your privacy declarations become short and true instead of long and risky.
• Cache the forecast, don't proxy it live. One scheduled job pulling the marine API and writing precomputed scores per launch site keeps your API bill flat regardless of users, and makes the app fast at a ramp on one bar of signal.
• Offline first. Your customer is at a boat ramp at dawn with no data. An app that needs the network to show yesterday's cached answer is broken in the moment it exists for.
• Location: coarse, on-device, when-in-use. Precise or always-on location buys you a nutrition-label entry, a permission prompt many people decline and a privacy obligation, for a feature that only needs to know which county you are in.
• Verify receipts server-side. Client-side entitlement checks are trivially bypassed and your audience is technically capable.
• Audit every SDK you add. Apple holds you responsible for what third-party code collects: "you need to identify all of the data you or your third-party partners collect", where third-party partners means "analytics tools, advertising networks, third-party SDKs, or other external vendors whose code you've added to your app" [1]. One convenience SDK can change your whole privacy posture without you noticing.
• Back up the only irreplaceable thing. Your source code and the launch-site dataset. The rest is rebuildable in a weekend.

Regional Compliance & Privacy

Three layers apply, and they do not have the same teeth. The platform layer can remove your product this month; the federal layer can fine you; the state layer mostly does not reach you yet, and is moving toward you.

The platform layer — the one that bites

Both stores require a privacy declaration before you can ship. Apple's App Privacy details require you to identify every data type you or your third-party partners collect, how it is used, whether it is linked to identity and whether it is used for tracking, plus a privacy policy link [1]. Guideline 5.1.1(i) requires that policy to identify what data is collected and all uses of it, confirm that third parties you share with provide equal protection, and explain your retention and deletion policies [2]. Google Play's Data safety section is the equivalent, and Google is blunt about the consequence of getting it wrong: "You alone are responsible for making complete and accurate declarations", and "Apps that don't become compliant are subject to policy enforcement, like blocked updates or removal from Google Play" [3]. That is the real risk — not a fine, but an inability to ship an update to your paying subscribers while you argue about a checkbox you filled in wrongly eighteen months ago.

App Tracking Transparency matters only if you decide to track, and you should not. Apple's position: "you need to receive the user's permission through the AppTrackingTransparency (ATT) framework in order to track them or access their device's advertising identifier", and without it "the device's advertising identifier value will be all zeros and you may not track them" [4]. Tracking means linking your data with data from other companies' apps or sites for advertising or measurement, or sharing with data brokers. You may not gate functionality on consent or incentivise it [4]. The practical upshot for a solo developer: skip advertising entirely and you can honestly answer "no" to the hardest questions on both forms.

Children — the trap you should close deliberately

A fishing app is not aimed at children, but children fish. COPPA applies to "operators of commercial websites and online services (including mobile apps...) directed to children under 13 that collect, use, or disclose personal information from children", and also to general-audience services with actual knowledge they are collecting from under-13s; civil penalties run to $53,088 per violation [5]. Apple's own guideline 5.1.4 requires care with children's data and states that apps in the Kids Category or apps that can share personal information from a minor "must include a privacy policy and must comply with all applicable children's privacy statutes"; Kids Category apps "may not send personally identifiable information or device information to third parties" and "should not include third-party analytics or third-party advertising" [2]. Your actions are simple and you should take all of them: do not select the Kids Category, set an age rating that is not child-directed, do not collect personal information at all, and do not build a feature — photo sharing, a catch log with images, a chat — that would give you actual knowledge of a child user.

State privacy law — not yet, and then suddenly

California's CCPA applies to businesses that have gross annual revenue over $25 million, buy, sell or share the personal information of 100,000 or more California residents or households, or derive 50% or more of annual revenue from selling California residents' personal information [6]. You meet none of those, and will not. But do not generalise from California, because the newer state laws are built differently. The Texas Data Privacy and Security Act applies to anyone who conducts business in Texas or produces a product or service consumed by Texas residents and processes personal data, with no revenue threshold at all — small businesses as defined by the federal Small Business Administration are generally exempt, except that selling sensitive data requires consent regardless; enforcement gives a 30-day cure period and then penalties of up to $7,500 per violation [7]. The direction of travel is clear: thresholds are falling and exemptions are getting narrower, and precise geolocation is treated as sensitive data in several of these statutes. Confirm the current position for the states your users are actually in before you start collecting location server-side. The cheapest compliance strategy available to you, by a wide margin, is to keep collecting nothing.

Risks & Common Pitfalls

• The distribution risk — the one that decides this. There is no channel in your budget that reaches 17,600 people. If the free launch guide site does not build a list in the first eight weeks, the app will not find users later, and you should stop before the build rather than after it.
• The 936 hours, spent once. Twelve hours a week for eighteen months is the real investment, and unlike the $9,000 it is not recoverable. Set a kill criterion now — a list size, a number of paying subscribers by month three — and write it down where you will read it when you do not want to.
• Churn eating the top of the funnel. At roughly 72% year-one annual cancellation [1] you are running up a down escalator. A seasonal utility is particularly exposed: the renewal notice arrives in the off-season, when the app has not been opened in three months.
• Rejection you did not plan for. Minimum functionality under guideline 4.2 and in-app account deletion under 5.1.1(v) [2] are the two that catch first-time solo developers. Both are cheap to satisfy before submission and expensive to discover in launch week.
• A privacy declaration that quietly becomes wrong. You add an analytics SDK in month eight and forget to update the form; Google's stated remedy is blocked updates or removal [3]. Put it on the release checklist permanently.
• Billing failures you never see. RevenueCat reports 31% of Google Play cancellations are caused by billing errors against 14% on the App Store [1] — recoverable churn you would otherwise mistake for people not liking the app.
• Data-supplier dependency. Your whole product is a layer on somebody else's forecast API. A price change, licence change or shutdown is an existential event.
• Liability from being believed. The better the app is, the more someone will trust it on a marginal day. Disclaimers in the product, not just the policy.
• Platform fee changes. Google's US fee structure changed on 30 June 2026 [4] and Apple's US external-purchase position has moved more than once. Do not model today's percentages as permanent.

Action Plan: 30 / 60 / 90 Days

Ninety days of this plan should cost you under $400 and should produce a yes-or-no answer on the only open question: will these people show up for you? Do not write app code in the first thirty days.

Days 1–30 — build the audience, not the app

• Publish the first fifteen launch-site pages as a plain static site. Fast, ugly, free, no signup wall. Cost: a domain.
• Post each one into the Florida kayak fishing groups and forums, as a person, not as a product. Count the members while you are there.
• Add one email capture line: "get the Gulf Coast launch report each Friday". The signup rate is your real verdict.
• Ask the groups whether they would pay for a launch-conditions app, and at what price. Record the answers verbatim, including the rude ones.
• Email two regional kayak fishing YouTube channels. No pitch, just the free site.

Days 31–60 — set up properly and start the clock on the platforms

• Enroll in the Apple Developer Program at $99 for the year [1] and register the Play Console account at $25 [2].
• Decide the structure with a Florida attorney, specifically on the liability question in section 11, then open the business bank account.
• Get the privacy policy and terms drafted, with a prominent in-product safety disclaimer.
• Read your marine data provider's licence for redistribution and paid-product clauses before you write a line against it.
• Recruit the 12 Play closed testers from the email list now, so the 14-day clock is off your critical path later.
• Ask a CPA one question: estimated payments versus increased withholding at the day job [3].

Days 61–90 — build the narrowest useful thing

• iOS only, eight launch sites, three features: the go/no-go score, the night-before notification, offline access. Nothing else.
• No accounts, no login, no server-side location — also the cheapest compliance posture available to you.
• Server-side receipt validation and a paywall you can change without shipping a build.
• TestFlight to twenty people off the email list, and watch where they stop in onboarding.
• At day 90, check the one number: is the email list growing without you posting? If it is, build the rest. If it is not, you have spent under $400 and ninety evenings to learn that this is a very good product with no way to reach anyone — worth knowing before the other 800 hours.