Southern Tide Media Sample brief

This is a sample with illustrative data. The business below is fictional and every number is invented to show the format — any resemblance to a real company is coincidence. This is the first deliverable of any app engagement: the document that decides whether the app should exist, written before anyone quotes you a build.

App Product Definition Brief

Prepared for: Pelican Point Outfitters (fictional example) · kayak retail, rentals and guided tours · August 2026

Recommendation: build the booking flow on the website first. Revisit the app in twelve months.

Two of the four things that justify a native app are genuinely present here, and two are not. The strongest use case — rental and tour booking — can be served by a mobile-optimized booking flow on the existing site for a fraction of the cost, and it will reach the walk-up customer who will never install anything. If the members program reaches roughly a thousand active repeat renters, the maths changes and we will say so.

The four-question test

An app earns its place on someone's home screen only when the answer to at least two of these is a clear yes. This is the same test we run on every app inquiry, including the ones that end in a build.

Question	Finding	Verdict
Do customers come back weekly or better?	Rental customers average 2.4 visits per season; the guided-tour list re-books roughly once a year. Only the 180-member season pass shows weekly behavior.	Not yet
Is there a genuine offline need?	Yes — tide tables, launch maps and safety information are used on the water where coverage drops out. This is the clearest app-shaped requirement found.	Yes
Do push notifications have something worth saying?	Yes — tide and weather windows, and last-minute tour openings. Currently sent by SMS with a 41% opt-out over the past year.	Yes
Is there a login people actually want?	Not broadly. 84% of bookings come from customers with no account, and account creation is the top drop-off point in the current checkout.	No

Figures above are illustrative. In a real brief every number comes from your own analytics, booking system and support history, and the sources are named line by line.

What the alternatives cost

$40k–400k+published market range for a custom mobile app build, basic to complex (source: Appinventiv 2026 cost guide)

15–25%of the build cost, per year, to keep an app alive as the platforms change (source: aggregated 2026 app-cost guides)

~$170kaverage custom app cost across a survey of 5,000+ projects (source: GoodFirms development-cost survey)

Against those numbers, the recommended path — a mobile booking flow, a tide-and-launch information section built for offline caching, and web push for tour openings — is a fraction of the cost and ships this season rather than next. That is the entire reason this document exists before a quote does.

If the app is built later, this is what it would be

The smallest genuinely useful version: season-pass login, offline tide tables and launch maps, push for tide windows and tour openings, and booking that reuses the same system as the website so staff learn one tool rather than two. Everything else — loyalty points, social sharing, an in-app store — waits until the first version proves people open it.

What happens next

Build the mobile booking flow and the offline-friendly tide and launch section on the existing site, quoted separately and priced in writing.
Instrument it: track repeat bookings per customer, so the app decision is made on data rather than instinct.
Re-run this brief in twelve months, or sooner if the season-pass program passes roughly a thousand active members.
If the numbers say build, the definition above becomes the scope, and the quote comes from that scope — not from a menu.

Every app engagement starts with this document, and it is allowed to conclude that you should not build an app — that is a real outcome here, not a rhetorical one. We would rather tell you that now than invoice you for finding out.

Get your AI Growth Snapshot