Western Cape tasting days, planned properly
App Store-ready landing page
Discover wineries, shape the route, and keep the day moving.
WineRoutes turns winery discovery into a clean mobile flow: map-first explore, smart route drafts, saved favourites, event discovery, and public support pages that are ready for store review.
Store buttons are wired to the live listing where configured.
Sunday route draft3 estates, 1 lunch stop
StellenboschFranschhoek
Balanced for tasting time, scenery, and low detoursRecommended flow
09:30Jordan Wine Estate
11:15Tokara
13:00Lunch with a view
15:10Lanzerac
Why WineRoutes converts
Built around the decisions people actually make before a wine day out.
The landing page leans on concrete product value instead of generic lifestyle copy: where to go, what fits the plan, and how quickly a route can be turned into action.
Map-first winery discovery
Search wineries by region, name, style, facilities, family-friendliness, or open-now filters without losing the sense of place.
Route planning that stays editable
Build a route draft, review the stop logic, then remove, reorder, or rebuild before anyone commits to the day.
Saved favourites and revisit flow
Keep recent wineries, saved estates, and draft routes close so a tasting weekend does not need to be replanned from scratch.
Event-aware exploration
Bring tastings, launches, and estate events into the same discover-and-plan surface instead of scattering them across channels.
Store-release trust pages
Ship support, privacy, terms, and delete-data pages as part of the public site instead of treating them like afterthoughts.
Western Cape-specific positioning
The product speaks to actual wine-route logistics, not generic travel platitudes, which makes the landing page sharper and more credible.
Experience flow
From map browse to a route you can actually follow.
Start from region, map, or current location
The first move is not a blank form. Users begin where they already are and browse winery options in the context of actual geography.
Tune the route to the day
Preferences like stop count, varieties, budget, facilities, and open-now behaviour shape the route before anyone gets in the car.
Save, revisit, and hand off
Routes can be stored, reopened, and handed off to navigation tools instead of dying as a one-off planning exercise.
What the app handles well
Nearby winery exploration anchored to the map
Search across regions, estate details, wines, and facilities
Suggested routes with stop reasoning and travel estimates
Saved drafts, favourites, and recent winery history
Support for reviews, profiles, and winery event discovery
Store-review friendly surface
The landing stack ships hosted support, privacy, terms, and delete-data pages so store metadata can point to stable public URLs from day one.
Trust and compliance
Public pages for support, privacy, terms, and account deletion are part of the release.
SupportGet help fast
Public contact details and response expectations for account issues, route bugs, and release support.
PrivacyReview data handlingExplain account, location, review, and permissions data in language clear enough for store metadata and users.
TermsSet service expectationsCover content accuracy, travel responsibility, and account conduct before launch traffic and store reviewers hit the app.
DeletionOffer a clean data-deletion pathProvide a stable account-deletion request page so release compliance does not depend on hidden support workflows.
FAQ
Questions people will ask before they download.
Is this page only marketing, or does it cover store-review requirements too?
It covers both. The homepage sells the product, while the support, privacy, terms, and delete-data pages give App Store and Play review the public URLs they expect.
Can the store buttons go live later without code changes?
Yes. The landing app reads public store URLs from deployment configuration, so the buttons can switch from support mailto links to live store listings during release.
Does the landing page depend on the backend runtime?
No. It is a static Next.js export deployed independently, which keeps the public site simple to host and safe to release without coupling it to the API.
Why keep the landing app separate from the Expo mobile project?
The mobile app and the landing site have different build outputs, hosting targets, and release concerns. Keeping them separate avoids forcing web marketing work into the Expo stack.
Ready for release
Launch the public surface alongside the mobile release instead of after it.
The landing app is designed to ship as a separate static deployment target, with store buttons, legal pages, SEO metadata, and release documentation all wired into the same repository.