SorongPass

Book speedboat seats and pay in seconds.

SorongPass is a web app for speedboat ticket booking in Sorong, Indonesia, with live schedules, seat availability, account management, and payment handling. It helps local passengers and travelers find departures, reserve seats, pay securely, and receive booking confirmations without relying on manual counter processes or scattered chat messages.

Business Goals

  • Increase online booking conversion to at least 35% of total ticket sales within 6 months of launch.
  • Reduce manual ticketing workload for participating operators by 50% within 3 months of onboarding.
  • Achieve 90% of bookings paid successfully online or via supported cashless methods within 6 months.
  • Reach 5,000 monthly active users and 1,500 monthly completed bookings by month 6.
  • Maintain a booking cancellation or payment dispute rate below 3% after the first 90 days.

User Goals

  • Let passengers check real departure schedules in under 30 seconds.
  • Allow users to reserve and pay for a seat without visiting the counter.
  • Provide clear booking status, ticket details, and payment confirmation in one place.
  • Help users manage profiles, passenger details, and booking history.
  • Give operators a simple way to publish schedules and available seats accurately.

Non-Goals

  • No full logistics fleet management or vessel maintenance system in the first release.
  • No dynamic surge pricing or marketplace bidding for seats.
  • No international airline-style loyalty program or multi-modal travel planner.
  • No offline-first native mobile app in phase 1; web app only with mobile-responsive design.

Traveling Passenger Rina, 29 - Rina travels from Sorong to nearby islands for work and family visits. She needs a fast way to see departure times, compare options, and pay without standing in line at the harbor.

Traveling Passenger Rina, 29

  • As a passenger, I want to see today's and tomorrow's boat schedules, so that I can choose the most convenient departure.
  • As a passenger, I want to reserve and pay for a seat from my phone, so that I do not need to queue at the ticket counter.
  • As a passenger, I want a booking confirmation and ticket reference, so that I can show proof of purchase at boarding.

Operator Admin Budi, 41 - Budi manages ticket sales for one boat route and updates departures based on vessel readiness, passenger demand, and weather conditions. He needs a simple dashboard that reduces phone calls and manual spreadsheets.

Operator Admin Budi, 41

  • As an operator admin, I want to create and edit schedules, so that passengers always see current departures.
  • As an operator admin, I want to track sold seats and payment status, so that I can avoid overbooking.
  • As an operator admin, I want to cancel or delay a trip and notify affected passengers, so that service disruptions are communicated quickly.

Counter Staff Sari, 34 - Sari helps passengers at the boarding counter and needs to quickly verify reservations and payment status. She works with customers who may have limited connectivity or prefer assisted booking.

Counter Staff Sari, 34

  • As counter staff, I want to search bookings by name, phone, or booking code, so that I can verify tickets quickly.
  • As counter staff, I want to mark a booking as checked in, so that boarding records stay accurate.
  • As counter staff, I want to help a customer pay and receive a receipt, so that walk-in sales are also captured in the system.

Schedule and Route Management · High priority

  • Publish and maintain speedboat departure schedules, routes, fares, and seat inventory for Sorong operators.
  • Support routes, departure times, terminal names, vessel names, fare classes, and seat counts.
  • Allow admins to create single departures and recurring schedule templates.
  • Update seat availability in real time when bookings are created, held, paid, canceled, or refunded.
  • Display schedule changes, delays, and cancellations prominently to users.
  • Prevent publishing departures with missing mandatory fields such as route, time, and fare.

Search, Booking, and Seat Reservation · High priority

  • Enable passengers to find trips, select a departure, reserve seats, and complete checkout on the web.
  • Provide schedule search by date, route, and departure time.
  • Create temporary seat holds for a short window, such as 10 minutes, while payment is completed.
  • Collect passenger details needed for boarding, including name and phone number.
  • Block overbooking by enforcing inventory locks at the transaction level.
  • Show clear error states when a departure sells out or is no longer available.

Payments and Transactions · High priority

  • Handle online payments and maintain reliable transaction records for every booking.
  • Integrate with Indonesian payment providers such as Midtrans or Xendit for VA, QRIS, and e-wallet payments.
  • Track transaction states including pending, paid, failed, expired, refunded, and reversed.
  • Generate booking receipts and downloadable payment confirmations.
  • Support webhook-based payment confirmation and retry-safe idempotency.
  • Allow admin review of disputed or failed transactions with audit history.

User Accounts and Booking History · Medium priority

  • Provide user authentication and a personal account area for managing bookings and payment records.
  • Allow sign up and login using phone number or email with OTP verification.
  • Show upcoming, completed, canceled, and refunded bookings in one account area.
  • Store basic traveler profile data to speed up repeat checkout.
  • Allow users to cancel within operator-defined rules if a trip is still eligible.
  • Send notification messages for payment confirmation, schedule changes, and departure reminders.

Admin Operations and Reporting · Medium priority

  • Give operators visibility into sales, occupancy, and operational exceptions.
  • Dashboard should show bookings by route, day, payment method, and status.
  • Allow staff roles with limited permissions for counter use, schedule edits, and refunds.
  • Export daily manifests and sales reports to CSV and PDF.
  • Log every schedule change, refund, and manual adjustment with user and timestamp.
  • Provide a simple search across bookings, passengers, and transactions.

Fast First Booking Journey

  • Open the web app on mobile or desktop and immediately see featured routes from Sorong.
  • Select route and travel date with only one required search action.
  • Review schedule options with price, seat availability, and departure time in a clean list.
  • Choose a trip, enter passenger details, and reserve seats.
  • Pay through QRIS, bank transfer, or supported e-wallet.
  • Receive booking confirmation and ticket code in under 3 minutes for a typical repeat user.

1. Find a trip

  • Users land on a route and schedule search experience optimized for quick decisions.
  • Default the search to popular Sorong routes and the current date.
  • Show sold-out departures clearly and avoid letting users tap into unavailable trips.
  • If schedules are missing or stale, show the last updated timestamp and a refresh prompt.

2. Select departure and seats

  • Users choose a specific trip and reserve seats before payment.
  • Show fare, remaining seats, terminal, and estimated duration before checkout.
  • Lock selected seats for a short time and display the hold countdown.
  • If the hold expires, release seats automatically and ask the user to restart checkout.

3. Enter passenger details

  • Users provide the minimum information needed for ticketing and boarding.
  • Collect name, phone number, and optional identification number if required by the operator.
  • Validate phone format and required fields before allowing payment.
  • Allow returning users to autofill saved traveler details from their account.

4. Pay and confirm

  • Users complete payment through integrated payment channels and get confirmation.
  • Show a clear order summary before redirecting to payment.
  • Handle payment callbacks and update status in near real time.
  • If payment fails or is pending, keep the booking visible with a retry or refresh action.

5. Use and manage ticket

  • Users view ticket details, history, and trip updates after booking.
  • Display booking code, route, departure time, and payment status in one ticket screen.
  • Send notifications for schedule changes, reminders, and successful payment.
  • Let users cancel or request support only when the operator policy allows it.

Power Tools and Edge Handling

  • Recurring schedule templates for busy routes and weekly departures.
  • Bulk seat and manifest export for operations teams.
  • Operator-triggered broadcast notices for delays, weather disruptions, and cancellations.
  • Role-based permissions for admins, cashiers, and supervisors.
  • Support for partial refunds, payment reconciliation, and manually confirmed cash payments.
  • Fraud and duplicate booking checks using phone, payment reference, and idempotency keys.

Design Principles for Speed and Trust

  • Mobile-first layout with large tap targets for travelers using low-end phones.
  • Strong contrast and readable typography for daylight harbor use and low-light conditions.
  • Status colors that are consistent across booking, payment, and trip states.
  • Accessible forms with inline validation, error recovery, and keyboard navigation.
  • Fast perceived performance with skeleton loading and cached schedule browsing.
  • Localized Indonesian language by default with support for Sorong-relevant route naming.

Rina needs to travel from Sorong to a nearby island the next morning. Instead of calling around or visiting the ticket counter, she opens SorongPass, checks departures, sees available seats, and completes her booking in a few taps on her phone.

She pays using QRIS, gets an instant confirmation, and saves her ticket code. When the operator updates the departure time later that day, she receives a notification immediately, so she arrives on time and avoids uncertainty at the harbor.

For the operator, the system replaces spreadsheets and manual phone confirmations with accurate inventory, payment tracking, and passenger records. That means fewer booking errors, faster checkout, and a smoother travel experience that can scale across more routes in Sorong.

User-Centric Metrics

  • Average time from landing to confirmed booking under 3 minutes for returning users.
  • At least 85% of users complete checkout without staff assistance.
  • Schedule search success rate above 95% with visible results for requested date/route.
  • Booking confirmation delivery success above 99% within 60 seconds of payment approval.
  • User satisfaction score of 4.5 out of 5 or higher after trip completion.

Business Metrics

  • 35% of total ticket sales processed online within 6 months.
  • Monthly completed bookings reach 1,500 by month 6.
  • Repeat booking rate reaches 40% within 90 days of first booking.
  • Operator onboarding conversion of at least 60% from demo to live usage.
  • Reduce counter handling time per booking by 50% compared with manual processing.

Technical Metrics

  • 99.9% monthly uptime for public booking and payment pages.
  • 95th percentile page load time under 2.5 seconds on mobile networks.
  • Payment webhook processing and booking status update within 30 seconds in 99% of cases.
  • Zero critical data loss incidents and encrypted storage for all sensitive records.

Tracking Plan

  • Track route_search_performed with route, date, and device type.
  • Track schedule_viewed with departure_id, availability, and load time.
  • Track seat_hold_created with hold duration and booking source.
  • Track checkout_started with payment method selection and passenger count.
  • Track payment_completed with provider, amount, and processing time.
  • Track booking_confirmed with trip, route, and confirmation delivery channel.
  • Track booking_canceled or payment_failed with reason codes for operational analysis.

Technical Needs

  • Frontend built with Next.js for SEO-friendly, mobile-responsive web pages.
  • Backend API using Node.js with NestJS or Express for booking, payment, and admin workflows.
  • PostgreSQL for transactional booking, inventory, and payment state records.
  • Redis for seat holds, rate limiting, and short-lived booking locks.
  • Object storage such as S3-compatible storage for receipts, manifests, and exports.
  • Background job queue such as BullMQ for payment reconciliation, reminders, and notifications.
  • CI/CD pipeline with automated tests, migrations, and environment-based deployment.

Integration Points

  • Midtrans or Xendit for payments, webhooks, and payout reconciliation.
  • WhatsApp Business API or Twilio for booking confirmations and schedule alerts.
  • Email delivery via SendGrid or Amazon SES for receipts and account messages.
  • Google Maps or route data source if location context is needed for terminals.
  • Authentication via OTP service such as Firebase Auth, Twilio Verify, or custom SMS gateway.

Data Storage & Privacy

  • Store only minimum passenger data required for ticketing and boarding.
  • Encrypt sensitive data at rest and use TLS for all traffic and webhook endpoints.
  • Implement role-based access control for operator, cashier, and super-admin actions.
  • Maintain audit logs for refunds, schedule edits, and manual booking overrides.
  • Provide data retention rules and user deletion processes aligned with local privacy requirements and GDPR or CCPA-style expectations where applicable.

Scalability & Performance

  • Use cached public schedule queries to keep search results fast during peak departure times.
  • Design payment and booking writes as idempotent operations to avoid duplicates under retries.
  • Separate read-heavy browsing traffic from transactional booking workflows.
  • Queue notification and reconciliation jobs so they do not slow down checkout.

Potential Challenges

  • Risk of overbooking from concurrent seat selection; mitigate with Redis locks and database transaction checks.
  • Risk of payment webhook delays or duplicates; mitigate with idempotency keys and retry-safe state transitions.
  • Risk of schedule inaccuracies from operator edits; mitigate with mandatory publish confirmation and audit logs.
  • Risk of low connectivity for users in harbor areas; mitigate with lightweight pages, compressed assets, and aggressive caching.
  • Risk of staff adoption resistance; mitigate with a simple admin UI, training materials, and phased rollout by route.

Team & resourcing - Small team - 2 full-stack engineers, 1 product designer, part-time PM, and shared QA/ops support.

Phase 1: MVP Booking Flow · Weeks 1-4

  • Public route and schedule browsing
  • Seat availability display
  • Basic account signup and login with phone or email
  • Checkout flow with seat hold and booking confirmation
  • Manual admin panel for schedule setup and booking lookup

Phase 2: Payments and Operations · Weeks 5-8

  • Midtrans or Xendit integration
  • Webhook-based transaction updates
  • Receipts and confirmation notifications
  • Admin refund and cancellation controls
  • Sales and occupancy dashboard

Phase 3: Reliability and Staff Tools · Weeks 9-12

  • Role-based permissions for admin and cashier users
  • Manifest export and advanced search
  • Schedule delay and cancellation notifications
  • Audit logs and reconciliation reports
  • Performance tuning for peak mobile traffic

Phase 4: Expansion and Optimization · Weeks 13-16

  • Recurring schedule templates
  • Bulk import for routes and departures
  • Improved analytics and funnel tracking
  • Support for more routes and operators around Sorong
  • Usability polish based on field feedback

Paste this into Cursor, Bolt, Lovable, or v0 to start building.

Build a mobile-first web app called SorongPass for speedboat ticket booking in Sorong, Indonesia.

Core product:
Passengers browse live schedules, reserve seats, pay online, and receive booking confirmations. Operators manage routes, departures, seat inventory, cancellations, refunds, and sales reporting. Counter staff can search and verify bookings quickly.

Tech stack:
Frontend: Next.js, TypeScript, Tailwind CSS, shadcn/ui
Backend: Node.js with NestJS or Express, TypeScript
Database: PostgreSQL with Prisma ORM
Cache/locks: Redis for seat holds and rate limiting
Jobs: BullMQ for payment reconciliation and notifications
Auth: phone/email OTP login
Payments: Midtrans or Xendit with webhook handling
Storage: S3-compatible object storage for receipts and exports

Required screens and flows:
1. Landing page with route/date search and featured departures
2. Search results list with price, seat availability, time, terminal, and sold-out states
3. Booking flow with seat hold countdown, passenger details form, payment selection, and confirmation
4. User account area showing upcoming, completed, canceled, and refunded bookings
5. Admin dashboard for route/schedule management, inventory, payment status, refunds, and reports
6. Counter staff booking lookup by name, phone, or booking code

Data model:
User, Operator, Route, Vessel, Departure, SeatInventory, Booking, BookingPassenger, PaymentTransaction, Refund, Notification, AuditLog, CheckIn

Key business rules:
Seat inventory must be locked atomically to prevent overbooking. Payment confirmation must be webhook-driven and idempotent. Booking holds expire after 10 minutes if unpaid. Admin edits to schedules must log an audit record. Users can only cancel when operator policy allows it.

Implementation details:
Create responsive mobile-first UI, clear status badges for pending/paid/failed/refunded, and accessible forms with inline validation. Add seeded demo data for Sorong routes. Include API routes, database schema, and realistic empty/loading/error states. Prioritize a clean, production-ready structure with reusable components and simple admin UX.

Business Idea

An web app to accommodate sorong's (indonesia) speedboat ticket booking and its schedule.include account for payment and transaction

Make My PRD

Design by The Resonance | Powered by GPC – The AI Transformation Company