WanderLive - mobile-first social travel platform

Existing social platforms contain travel content but lack tools optimized for travel discovery and geographic exploration.

Fragmentation of travel content

Travel experiences are currently spread across:

• Instagram
• TikTok
• YouTube
• travel blogs
• Google Maps reviews

This fragmentation prevents travelers from easily exploring locations through real traveler experiences.

Poor geographic discovery

Platforms like Instagram allow location tagging but provide limited discovery capabilities.

Limitations include:

• poor search interfaces
• no geographic browsing
• limited filtering by place
• lack of map visualization

Travelers often rely on:

• Google Maps reviews
• travel blogs
• YouTube search

None provide real-time or experiential discovery.

Lack of real-time travel insight

Most travel content is asynchronous.

Users cannot easily see:

• what is happening at a destination right now
• how crowded places are
• current events or conditions

Live travel broadcasting is rare and scattered across general platforms.

Lack of structured travel identity

Current platforms do not track or represent:

• countries visited
• travel progression
• travel achievements
• geographic travel history

This limits the ability for travelers to build a meaningful public travel identity.

Primary persona — Active Travelers

Characteristics:

• travel frequently
• document trips via photos and videos
• share experiences online
• interested in social engagement

Typical profiles:

• digital nomads
• backpackers
• travel influencers
• remote workers
• adventure travelers

Technical profile:

• comfortable with mobile apps
• active on Instagram or TikTok
• familiar with live streaming

Motivation:

• documenting journeys
• growing an audience
• sharing travel tips

Secondary persona — Travel Explorers

Users who primarily consume content rather than create it.

Characteristics:

• planning future travel
• researching destinations
• discovering hidden places
• exploring travel culture

Motivation:

• destination discovery
• trip planning
• entertainment

Creator segment

A subset of users who monetize travel content.

Characteristics:

• maintain travel-focused audiences
• publish high-frequency content
• use analytics to track engagement

Monetization potential:

• live stream gifts
• subscriptions
• travel brand partnerships

The MVP focuses on delivering the core platform value:

geotagged travel media + map discovery + live streaming

Core MVP features

User system:

• account registration
• login via email or OAuth
• public traveler profiles
• follow system

Content creation:

• upload photo posts
• upload short videos
• attach location tag
• caption text

Map exploration:

• interactive world map
• pins representing posts
• zoom-based clustering

Live streaming:

• start live stream
• real-time viewer count
• live chat

Discovery:

• location search
• hashtag search
• trending places feed

Social features:

• like posts
• comment on posts
• follow travelers

Moderation basics:

• report content
• block users

Analytics:

• view count
• engagement metrics

The system uses a mobile-first microservices architecture optimized for media processing and real-time interactions.

Core system components

Frontend:

• mobile applications
• optional web client

Backend services:

• user service
• content service
• live streaming service
• geolocation service
• feed service
• notification service

Infrastructure services:

• CDN
• object storage
• search engine
• real-time messaging

Architecture flow

Content creation pipeline:

1. user uploads media
2. media stored in object storage
3. metadata stored in database
4. media processed asynchronously
5. search index updated
6. content becomes discoverable

High-level architecture diagram

Mermaid representation:

graph TD

MobileApp --> API Gateway

API Gateway --> UserService
API Gateway --> ContentService
API Gateway --> FeedService
API Gateway --> StreamService

ContentService --> ObjectStorage
ContentService --> PostgreSQL
ContentService --> SearchIndex

StreamService --> StreamingProvider
StreamService --> Redis

FeedService --> Redis
FeedService --> PostgreSQL

NotificationService --> PushProvider

Deployment model

Containerized services deployed via:

• Kubernetes or container orchestration
• auto-scaling groups for streaming workloads

Primary relational database: PostgreSQL.

Users table

users
-----
id UUID PK
username TEXT UNIQUE
email TEXT
password_hash TEXT
bio TEXT
profile_image_url TEXT
country TEXT
created_at TIMESTAMP

Posts table

posts
-----
id UUID PK
user_id UUID FK
caption TEXT
media_type TEXT
media_url TEXT
location_id UUID
visibility TEXT
created_at TIMESTAMP

Locations table

locations
---------
id UUID PK
name TEXT
country TEXT
latitude FLOAT
longitude FLOAT
place_type TEXT

Live streams table

live_streams
------------
id UUID PK
user_id UUID FK
location_id UUID
status TEXT
viewer_count INT
started_at TIMESTAMP
ended_at TIMESTAMP

Engagement tables

Likes:

likes
-----
user_id UUID
post_id UUID
created_at TIMESTAMP

Comments:

comments
--------
id UUID PK
post_id UUID
user_id UUID
content TEXT
created_at TIMESTAMP

Follows:

follows
-------
follower_id UUID
following_id UUID
created_at TIMESTAMP

Indexing recommendations

Indexes should exist for:

• posts.location_id
• posts.created_at
• live_streams.status
• follows.follower_id

API follows REST conventions with JSON responses.

Authentication

JWT-based authentication.

Header format:

Authorization: Bearer <token>

Core endpoints

User registration:

POST /api/auth/register

Create post:

POST /api/posts

Request:

{
 "caption": "Sunset in Santorini",
 "location_id": "uuid",
 "media_url": "..."
}

Feed retrieval:

GET /api/feed

Location search:

GET /api/locations/search?q=tokyo

Start live stream:

POST /api/live/start

Join live stream:

GET /api/live/{id}

Comment on post:

POST /api/posts/{id}/comments

Follow user:

POST /api/users/{id}/follow

Mobile frontend

React Native.

Reasons:

• cross-platform development
• large ecosystem
• fast iteration

Alternative:

Flutter.

Backend

Node.js with TypeScript.

Framework options:

• NestJS
• Express with modular architecture

Reasons:

• strong async support
• large developer ecosystem

Database

PostgreSQL.

Reasons:

• relational consistency
• strong geospatial extensions
• indexing performance

Geospatial queries

PostGIS extension for:

• distance calculations
• geo-radius queries

Search

Elasticsearch.

Used for:

• location search
• hashtag search
• trending queries

Real-time systems

Redis + WebSockets.

Used for:

• live chat
• viewer counters
• notifications

Media storage

AWS S3.

Streaming infrastructure

AWS IVS or Mux.

Reasons:

• managed live streaming
• scalable infrastructure

CDN

Cloudflare or CloudFront.

Authentication:

• JWT tokens
• refresh token rotation
• bcrypt password hashing

Authorization:

• role-based permissions
• user-specific access rules

Data protection:

• HTTPS enforced
• encrypted storage for sensitive data

Rate limiting:

• API gateway rate limiting
• IP throttling

Content moderation:

• AI image detection
• manual review queue

Streaming security:

• signed playback tokens
• stream access control

Abuse protection:

• spam detection
• account activity monitoring

Initial monetization model follows a creator economy framework.

Freemium tier

Free users:

• publish content
• watch live streams
• basic discovery

Premium tier:

• advanced analytics
• profile verification
• custom travel maps

Live stream gifts

Users purchase virtual gifts during streams.

Revenue model:

• platform takes percentage

Creator subscriptions

Followers subscribe for exclusive travel content.

Promoted destinations

Tourism boards pay for promoted visibility.

Affiliate revenue

Travel bookings integrated via affiliate APIs.

Launch strategy targets travel creator communities.

Phase 1

Invite early adopters:

• travel influencers
• travel vloggers
• digital nomads

Phase 2

Community expansion via:

• travel Facebook groups
• Reddit travel communities
• creator partnerships

Phase 3

SEO-driven growth through:

• searchable travel content
• location landing pages

Before building full product, validate interest.

Pre-MVP validation

Landing page explaining the concept.

Collect:

• email waitlist
• creator signups

Prototype validation

Clickable mobile prototype.

User testing with travelers.

Metrics

Track:

• signups
• live stream usage
• content uploads
• retention

Phase 1 — MVP (3–4 months)

Features:

• user accounts
• photo/video posts
• location tagging
• map discovery
• basic live streaming

Phase 2 — Community expansion

Features:

• travel groups
• advanced feeds
• improved discovery

Phase 3 — Creator economy

Features:

• gifts
• subscriptions
• analytics dashboards

Technical risks:

• live streaming infrastructure complexity
• scaling media storage

Market risks:

• competing with large social platforms

Legal risks:

• content moderation requirements
• privacy regulations

Competitive risks:

• large platforms copying travel features

Future features may include:

AI travel recommendation engine.

Augmented reality travel overlays.

Travel itinerary builders.

Local experience marketplace.

Offline travel guides based on saved posts.

You are a senior full-stack engineer building the MVP for “WanderLive” — a mobile-first social travel platform where users can post geotagged travel photos/videos, start live streams from locations, explore the world through an interactive map, and discover places through real traveler content.
Implement a production-ready but minimal system with a React Native (Expo) mobile app, a NestJS (Node/TypeScript) backend API, and supporting infrastructure for media uploads, geospatial discovery, real-time chat, and live stream orchestration. Use PostgreSQL + PostGIS, Redis, and S3-compatible object storage. Use a managed live streaming provider such as Mux, AWS IVS, or equivalent abstraction.
GOALS (MVP)
A user can sign in, create a profile, and maintain a public traveler identity.
Email magic link or OTP login is acceptable for MVP.
User profile includes username, bio, avatar, home country, privacy setting.
User can follow/unfollow other travelers.
A user can create travel posts.
Upload one or more photos.
Upload one short video.
Add caption.
Add location via GPS coordinates or place search.
Choose visibility: public / followers-only / private.
A user can explore travel content through a map and feeds.
“For You” feed with simple ranking logic.
“Following” feed in reverse chronological order.
Interactive map with clustered pins.
Search by city, country, or place name.
Search by hashtag/location-style tags.
A user can start and end a live stream tied to a place.
Create live session from current location or selected place.
Followers receive push notification when a stream starts.
Users can join live stream detail view.
Viewers can send messages and reactions in real time.
Stream metadata is archived when live ends.
A user can engage socially.
Like posts.
Comment on posts.
Save/bookmark posts.
Follow users.
Report content or users.
The platform provides basic creator/traveler analytics.
Profile stats: posts, followers, countries visited, cities explored.
Post stats: views, likes, comments, saves.
Live stats: total viewers, peak viewers, total chat messages.
The system is designed so that later phases can add:
gifts/subscriptions
advanced recommendation engine
group travel communities
creator monetization
tourism board promoted locations
TECH STACK
Mobile: React Native (Expo), TypeScript, React Query, Zustand, Expo Router, expo-location, expo-image-picker, expo-notifications, react-native-maps or Mapbox SDK.
Backend: NestJS + TypeScript, Prisma ORM, PostgreSQL + PostGIS, Redis, JWT auth.
Realtime: Socket.IO or WebSocket gateway in NestJS for chat, reactions, live presence, and notifications fan-out.
Storage: S3-compatible object storage (AWS S3, Cloudflare R2, or MinIO for local dev).
Media processing: ffmpeg job pipeline for video thumbnails/transcoding metadata; image optimization on upload complete.
Search: PostgreSQL full-text for MVP, with abstraction layer so Elasticsearch / Meilisearch can be introduced later.
Streaming: Mux or AWS IVS. Implement a provider abstraction so the backend is not tightly coupled to one vendor.
Infra: Docker Compose for local dev; deploy API + workers via ECS Fargate / Fly.io / Render; Postgres via RDS / Supabase / Neon; Redis via Upstash / ElastiCache.
Push notifications: Expo Push API or Firebase Cloud Messaging abstraction.
Observability: structured logs, request IDs, health endpoints, basic metrics.
DELIVERABLES
A) Monorepo with:
/apps/mobile
/apps/api
/apps/worker
/packages/shared
B) Docker Compose that runs:
postgres + postgis
redis
api
worker
minio (or local S3-compatible dev storage)
C) Prisma schema + migrations matching the models below.
D) REST API endpoints with validation, auth, pagination, and authorization rules.
E) Minimal mobile UI flows:
Sign in / onboarding
Create profile
Home feed
Explore map
Search places / tags
Create post flow
Post detail
Traveler profile
Live stream creation and live room
Notifications screen
Saved posts screen
Reporting flow
F) Worker/job processing for:
media finalization
video thumbnail generation
geospatial stats aggregation
notifications dispatch
travel stats recomputation
G) Seed script to load:
50 sample locations
100 example hashtags/tags
a few demo users
a few sample posts for map/feed testing
CORE PRODUCT BEHAVIOR
Traveler identity
Each user has a public traveler profile.
Profile shows avatar, username, bio, follower counts, following counts.
Profile shows travel stats derived from posts:
countries visited
cities explored
total posts
live stream count
Privacy settings supported:
public account
private account
exact location sharing enabled/disabled
Posts
A post may contain:
1..10 images, or
1 video
Each post has:
caption
visibility
optional hashtags
associated place
optional raw coordinates
The API must separate:
upload initiation
upload completion
post publishing
Exact coordinates should not automatically be exposed publicly if the user selects reduced precision.
Place model
Store normalized places separately from raw coordinates.
Support:
city
region/state
country
point-of-interest
Use PostGIS geometry/geography types where appropriate.
For MVP, a simplified place search table is acceptable, but model it in a way that allows later syncing with Mapbox/Google Places/OpenStreetMap providers.
Map exploration
Map should show clustered content pins.
Query by bounding box:
north-east / south-west bounds
Filter by:
content type
recent activity
live now
Tapping a cluster zooms in.
Tapping a pin opens lightweight content preview.
Feeds
“Following” feed:
reverse chronological posts from followed users
“For You” feed:
simple heuristic ranking using:
followed users boost
recent posts boost
high engagement boost
nearby places boost
Do not implement a complex ML recommendation engine for MVP.
Keep ranking logic deterministic and adjustable in code.
Live streaming
User can create a live session with title + associated place.
Backend requests live ingest/playback data from streaming provider.
Live session states:
created
live
ended
archived
When stream ends:
store analytics snapshot
mark session archived
optionally generate replay metadata entry
Viewers can:
join live room
send chat messages
send reactions
For MVP, chat history may be ephemeral or stored with TTL plus archived summary.
Social interactions
Likes, comments, saves/bookmarks, follows.
Mentions parsing optional but structure code for later support.
Reporting and blocking required.
Blocked users cannot:
comment
follow
send live chat messages visible to blocker
Analytics
Aggregate tables or materialized views for:
post metrics
profile metrics
live metrics
Stats can be eventually consistent via background jobs.
MONOREPO STRUCTURE
/apps
/mobile
/api
/worker
/packages
/shared
- types
- DTO contracts
- zod schemas
- constants
- feed ranking utils (shared if useful)
app responsibilities
/apps/mobile
React Native Expo app
authentication flow
feeds
map exploration
post creation
live room UI
profile and settings
/apps/api
NestJS API
auth
users/profiles
posts/media
places/search
feeds
follows
comments/likes/saves
live session orchestration
notification endpoints
reporting/moderation basics
/apps/worker
BullMQ or equivalent job workers
media processing
notifications
metrics aggregation
post-publication indexing
archive/live-end jobs
/packages/shared
shared DTOs
enums
validation schemas
API response types
common constants
DATABASE SCHEMA (Prisma models)
Implement Prisma models equivalent to the following entities.
User
id
email
username
passwordHash (nullable if magic link only)
authProvider
status
createdAt
updatedAt
UserProfile
userId
displayName
bio
avatarObjectKey
homeCountryCode
isPrivate
shareExactLocation
createdAt
updatedAt
Follow
id
followerId
followingId
status (active / pending if private profiles later)
createdAt
Place
id
provider
providerPlaceId
name
slug
countryCode
countryName
regionName
cityName
latitude
longitude
geoPoint
placeType
createdAt
Post
id
userId
placeId
caption
visibility
contentType (image_gallery / video)
status (draft / processing / published / hidden)
publishedAt
createdAt
updatedAt
PostMedia
id
postId
mediaType (image / video)
objectKey
thumbnailObjectKey
width
height
durationSeconds (nullable)
sortOrder
createdAt
PostTag
id
postId
tag
normalizedTag
PostLike
id
postId
userId
createdAt
PostComment
id
postId
userId
parentCommentId (nullable for threading-ready model)
body
status
createdAt
SavedPost
id
userId
postId
createdAt
FeedEvent
id
userId
postId
eventType (impression / open / like / save / comment / share)
createdAt
LiveSession
id
userId
placeId
title
description
provider
providerStreamId
ingestUrl
streamKeyEncrypted
playbackUrl
status
startedAt
endedAt
archivedAt
peakViewerCount
totalViewCount
totalChatCount
createdAt
LiveChatMessage
id
liveSessionId
userId
body
messageType (text / reaction / system)
createdAt
Notification
id
userId
type
payloadJson
readAt
createdAt
DevicePushToken
id
userId
platform
token
createdAt
updatedAt
UserBlock
id
userId
blockedUserId
createdAt
Report
id
reporterUserId
targetType (post / comment / live_session / user)
targetId
reasonCode
details
status
createdAt
ProfileStatSnapshot
id
userId
postCount
followerCount
followingCount
countryCount
cityCount
liveCount
updatedAt
PostStatSnapshot
id
postId
viewCount
likeCount
commentCount
saveCount
updatedAt
LiveStatSnapshot
id
liveSessionId
peakViewerCount
totalViewCount
totalChatCount
updatedAt
DATABASE / INDEXING REQUIREMENTS
Use PostgreSQL + PostGIS.
Add unique constraints where appropriate:
User.email
User.username
Follow(followerId, followingId)
SavedPost(userId, postId)
PostLike(postId, userId)
Add indexes for:
Post.userId
Post.placeId
Post.publishedAt
Place.geoPoint
LiveSession.status
LiveSession.placeId
PostTag.normalizedTag
Notification.userId, createdAt desc
Add geospatial query support for:
nearby content
bounding box queries
country/city aggregations
API ENDPOINTS (NestJS)
Prefix all routes with /v1.
Auth
POST /v1/auth/login
email magic link / OTP stub acceptable
returns access + refresh token
POST /v1/auth/refresh
POST /v1/auth/logout
Me / Profile
GET /v1/me
PATCH /v1/me/profile
POST /v1/me/avatar/presign
POST /v1/me/avatar/complete
Users
GET /v1/users/:username
POST /v1/users/:id/follow
DELETE /v1/users/:id/follow
POST /v1/users/:id/block
DELETE /v1/users/:id/block
Places
GET /v1/places/search?q=...
GET /v1/places/:id
GET /v1/places/:id/posts
GET /v1/places/:id/live
Posts
POST /v1/posts
create draft post record
POST /v1/posts/:id/media/presign
returns upload URL + objectKey
POST /v1/posts/:id/media/complete
finalize uploaded asset
POST /v1/posts/:id/publish
validate required fields and publish
GET /v1/posts/:id
DELETE /v1/posts/:id
POST /v1/posts/:id/like
DELETE /v1/posts/:id/like
POST /v1/posts/:id/save
DELETE /v1/posts/:id/save
POST /v1/posts/:id/comments
GET /v1/posts/:id/comments
Feed
GET /v1/feed/following?cursor=...
GET /v1/feed/for-you?cursor=...
GET /v1/feed/nearby?lat=...&lng=...&radiusKm=...
Explore / Map
GET /v1/explore/map?minLat=...&minLng=...&maxLat=...&maxLng=...&zoom=...
returns clustered pins and lightweight summaries
GET /v1/explore/tags?q=...
GET /v1/explore/trending
GET /v1/explore/live-now
Live sessions
POST /v1/live-sessions
create live session and request provider stream details
POST /v1/live-sessions/:id/start
POST /v1/live-sessions/:id/end
GET /v1/live-sessions/:id
GET /v1/live-sessions/:id/chat
POST /v1/live-sessions/:id/chat
POST /v1/live-sessions/:id/reaction
Notifications
GET /v1/notifications
POST /v1/notifications/register-device
POST /v1/notifications/:id/read
Reporting / moderation
POST /v1/reports
GET /v1/me/reports
REQUEST / RESPONSE EXAMPLES
Create draft post
POST /v1/posts
{
  "caption": "Golden hour over the cliffs.",
  "placeId": "plc_123",
  "visibility": "public",
  "contentType": "image_gallery",
  "tags": ["sunset", "santorini", "cliffwalk"]
}
Response:
{
  "id": "pst_123",
  "status": "draft"
}
Publish post
POST /v1/posts/:id/publish
{
  "confirm": true
}
Response:
{
  "id": "pst_123",
  "status": "published",
  "publishedAt": "2026-03-07T18:00:00.000Z"
}
Create live session
POST /v1/live-sessions
{
  "title": "Night market walk",
  "description": "Walking through food stalls and local shops.",
  "placeId": "plc_888"
}
Response:
{
  "id": "liv_123",
  "status": "created",
  "provider": "mux",
  "ingestUrl": "rtmps://...",
  "streamKey": "secure-temporary-value",
  "playbackUrl": "https://stream.example/playback.m3u8"
}
REALTIME REQUIREMENTS
Use Socket.IO or equivalent WebSocket gateway.
Support namespaces/channels for:
live chat
reactions
presence/viewer counts
server-side event fan-out for notifications
Realtime events
live:join
live:leave
live:message
live:reaction
live:viewer_count
notification:new
rules
authenticate socket connections with JWT
rate limit chat messages and reactions
reject blocked users from room interactions where relevant
maintain simple in-memory or Redis-backed room presence counters
FEED RANKING LOGIC (MVP)
Implement a deterministic ranking function in the API or worker layer.
Suggested formula inputs:
freshness score
following relationship boost
engagement score
location relevance boost
live-now boost where applicable
Example conceptual scoring:
recent post within 24h: +30
from followed user: +25
high engagement percentile: +20
same country as viewer: +10
nearby city: +15
Do not over-engineer this. Keep it explainable and configurable via constants.
MEDIA WORKFLOW
Images
mobile app requests presigned upload
upload directly to S3
notify API on completion
API stores asset metadata
worker can optionally optimize/compress variants
Videos
direct upload to object storage for MVP
worker extracts:
duration
width/height
poster thumbnail
mark media processing state in DB
prevent publishing if required processing is incomplete
Privacy
originals remain private in storage
serve via signed URLs or controlled CDN strategy
do not expose bucket URLs directly
GEO / MAP REQUIREMENTS
Use PostGIS and map-based query endpoints.
Required queries
fetch posts in viewport bounding box
cluster approximate points by zoom level
nearby content within radius
user travel stats by distinct city/country
Precision controls
If shareExactLocation = false:
public payloads should expose rounded coordinates or place-level location only
raw coordinates remain private internally if needed
MOBILE UI REQUIREMENTS
Implement a minimal but polished Expo app with the following screens.
Authentication
email input
code input / mock OTP
session persistence
Onboarding
choose username
add avatar
add bio
choose privacy and location-sharing preferences
Home
top tabs: For You / Following
card-based feed with image/video
actions: like, comment, save, open place
Explore
interactive map
bottom sheet for selected pins
search bar for places/tags
quick filters: live now, trending, nearby
Create Post
image/video picker
caption input
tag input
place search or current location attach
visibility selector
publish action
Post Detail
media carousel or video player
comments list
place summary
author info
Profile
avatar, bio, stats
grid/list of posts
visited countries count
follow/unfollow
saved tab (only on own profile)
Live
create live setup screen
live room with chat overlay and reaction button
live detail / watch screen
Notifications
follow alerts
live started alerts
likes/comments on posts
Settings / Safety
block list
privacy controls
report flow
WORKER / BACKGROUND JOBS
Use BullMQ or equivalent.
Required jobs:
media.finalize
video.thumbnail.generate
post.publish.validate
profile.stats.recompute
place.stats.recompute
live.started.notify_followers
live.ended.archive
notifications.push.dispatch
worker expectations
idempotent jobs
retry policy with dead-letter behavior
structured logs
correlation IDs propagated from API when useful
STREAMING PROVIDER ABSTRACTION
Create an internal service interface such as:
createStreamSession()
getPlaybackUrl()
markLiveStarted()
markLiveEnded()
Implement one concrete provider first, e.g. Mux.
Do not scatter provider-specific logic across controllers. Keep it inside a dedicated module/service so switching vendors later is manageable.
AUTH / SECURITY REQUIREMENTS
JWT access + refresh tokens
route guards for protected endpoints
ownership checks for editing/deleting posts
rate limit auth, comments, reactions, reports
validate all inputs with class-validator or Zod
sanitize captions/comments
structured moderation statuses:
active
hidden
flagged
removed
basic audit logging for moderation-sensitive actions
signed URLs for private media
encrypted storage for secrets and stream keys
NOTIFICATIONS
Implement notification creation in backend and delivery abstraction.
MVP notification types:
followed_you
liked_post
commented_post
stream_started
report_update
Store all notifications in DB. Push delivery can fail independently without losing in-app history.
ANALYTICS / STATS REQUIREMENTS
Do not compute expensive stats on every request.
Use snapshots / aggregation jobs.
Profile stats
total posts
follower count
following count
distinct countries from published posts
distinct cities from published posts
total live sessions
Post stats
views
likes
comments
saves
Live stats
peak viewers
total viewers
total messages
Implement eventual consistency. Small lag is acceptable.
SEARCH REQUIREMENTS
For MVP:
use PostgreSQL ILIKE and full-text search where enough
normalize tags into a separate table
normalize place search terms
expose clean DTOs so search backend can later move to Elasticsearch or Meilisearch without breaking clients
LOCAL DEV
Provide:
docker-compose.yml
.env.example for each app
seed scripts
README with:
install steps
migration commands
how to start Expo app
how to run worker
how to configure object storage
how to configure streaming provider sandbox credentials
Local stack should boot with one command as much as possible.
DEPLOYMENT
Provide Dockerfiles for:
api
worker
Provide deployment notes for:
Postgres/PostGIS
Redis
S3 bucket / R2 bucket
API service
worker service
Expo EAS build notes
streaming provider env vars
secrets management
Recommended production topology:
managed Postgres
managed Redis
object storage bucket
API service
worker service
CDN
push notification credentials
streaming provider account
Optional:
Terraform notes or deployment checklist, but not required for MVP.
QUALITY BAR
strong module boundaries in NestJS
DTO validation everywhere
centralized exception filter
request logging middleware
correlation/request IDs
pagination for list endpoints
cursor-based feeds where practical
unit tests for:
feed ranking
visibility rules
follow/block rules
post publish validation
integration tests for key endpoints:
auth
create post
publish post
follow user
live session create/end
NON-GOALS FOR MVP
Do not implement yet:
advanced ML recommendation engine
full private-account follow approval flows beyond basic structure
in-app payments
virtual gifts economy
subscriptions
creator payouts
group travel communities
offline map support
full web client parity
Keep code structured so these can be added later.
IMPLEMENTATION NOTES
Prefer a clean domain model over premature microservices. Keep MVP deployable as one API app plus one worker app.
Use modular NestJS architecture:
auth
users
profiles
posts
places
feeds
live-sessions
notifications
moderation
stats
Keep media upload flow resumable-friendly if possible, but simple presigned uploads are enough for MVP.
Design DTOs so the mobile app receives place summaries and privacy-safe location payloads by default.
Create reusable visibility guards:
public
followers-only
private
Store hashtags normalized and lowercase.
Encapsulate geospatial query logic in repository/service layer, not controllers.
Keep live chat and reactions lightweight. Prioritize reliability over feature depth.
FINAL TASK
Now implement the MVP end-to-end for WanderLive with:
monorepo structure
React Native Expo mobile app
NestJS API
worker service
Prisma/Postgres/PostGIS schema
Redis-backed jobs
object storage uploads
map exploration
social interactions
live stream orchestration abstraction
notifications
analytics snapshots
tests and documentation
Build it as a clean, extensible codebase that is minimal for MVP but structurally ready for future scale.