Can FareHarbor be vibe coded?

Build brief — a focused alternative to FareHarbor

Verdict: Partly, if you narrow it · Buildability: 33/100 · Category: Travel

Source: https://www.canitbevibecoded.com/fareharbor

Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from FareHarbor. Verify current pricing and capabilities before acting.

Context

FareHarbor — Booking, availability and payment software for tour, activity and rental operators, with distribution out to the big OTAs.

The part everyone thinks they are paying for, a calendar with capacity, a checkout, and a manifest the guides can read, is genuinely a focused build with Stripe doing the hard money parts. The part that is actually load-bearing is everything after that: pushing live availability to Viator, GetYourGuide, Expedia and Booking.com, reconciling reseller commissions, handling refunds and chargebacks on other people's money, and a phone line that answers at 6am when the 7am kayak trip is double-booked. A self-hosted build replaces direct-website bookings cleanly and replaces channel distribution not at all. If most of your volume is direct and you can eat the ops burden, the maths gets interesting fast. If OTAs feed you, you are rebuilding a channel manager, which is not a focused implementation.

This brief describes a focused, single-operator replacement for the part of FareHarbor that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

What you are building

Self-hosted booking site: define tours with dated departures and capacity, take deposits or full payment through Stripe Checkout, and give staff a day-view manifest with check-in and cancellation.

Build an itinerary from saved places, dates, and budgets you control.

A responsive interface with real empty, loading, success, and error states.

Requirements

Functional

Stripe account (test mode is fine to build against).

A domain and any Node host, plus a Postgres or SQLite volume.

Transactional email provider for confirmations.

Clear rules for your own cancellation, deposit and capacity logic before you start.

Non-functional

Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.

Security: server-side secrets, validated input, and no credentials in the client bundle.

Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.

Portability: the operator can export their data and leave without losing it.

Implementation brief

Build a self-hosted booking system for a single tour operator. Stack: Next.js 15 with the App Router, TypeScript, Tailwind, Postgres via Prisma, Stripe Checkout. No auth provider, no analytics, no telemetry.

Data model: Product (name, slug, description, duration minutes, base price cents, currency, min and max party size, active flag), Departure (product, start datetime, capacity, status: scheduled | cancelled), Booking (departure, lead name, email, phone, party size, amount cents, stripe payment intent id, status: pending | confirmed | cancelled | refunded, notes, waiver accepted at), Passenger (booking, name, age band).

Public side:

/tours lists active products, /tours/[slug] shows the next 60 days of departures with seats remaining computed as capacity minus confirmed and pending party sizes.

Booking flow: pick a departure, enter party size and lead contact, tick a waiver checkbox, then redirect to Stripe Checkout. Create the Booking as pending before redirect. Confirm it only in the Stripe webhook handler, never on the return URL.

Overselling is the thing you must get right: take the seat hold inside a serialisable transaction that re-checks remaining capacity, and expire pending bookings older than 20 minutes with a cron route.

Operator side at /admin, protected by a single shared password from .env stored in an httpOnly cookie:

Day view manifest: every departure today with lead names, party sizes, phone numbers, waiver status and a check-in toggle.

Create and bulk-generate departures from a weekday recurrence rule with a date range.

Cancel a departure: refunds all confirmed bookings through the Stripe API and emails everyone.

Manual booking entry for phone and walk-up guests, marked as unpaid or cash.

CSV export of bookings for a date range.

Email confirmations and cancellations via Resend, plain text, with an .ics attachment. Money in integer cents, one currency, store all times in UTC and render in a single operator timezone from .env.

Explicitly out of scope: OTA or reseller channel sync, promo codes, gift cards, multi-day itineraries, guide and equipment assignment, multi-currency, per-user accounts and roles.

Secrets in .env: DATABASE_URL, STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET, RESEND_API_KEY, ADMIN_PASSWORD, OPERATOR_TIMEZONE. Ship a seed script with two products and 30 days of departures, a README with the Stripe CLI webhook command, and a test that proves a departure cannot be oversold under concurrent requests.

Delivery standard

Inspect the repository first, then write a short implementation plan before writing code.

Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.

Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.

Include responsive layouts plus genuine empty, loading, success, validation, and failure states.

Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.

Add structured logs around every external call and return actionable errors without leaking sensitive details.

Write unit tests for the core logic and one automated test of the main user journey.

Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

Acceptance criteria

A clean install starts the app using only the README and .env.example.

The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.

Invalid input, missing configuration, provider failure, and an empty database each have a usable state.

The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.

Tests, type checking, linting, and a production build all pass with no ignored failures.

No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

Non-goals

Do not build these, and do not claim to have replaced them:

OTA and reseller distribution: live availability pushed to Viator, GetYourGuide, Expedia and dozens of local agents, plus the commission accounting behind it.

Someone else owning payment risk: chargebacks, disputes, refund flows, payout timing, PCI scope and multi-currency.

24/7 human support during a season where a broken booking page costs real departures that day.

The messy operational features you only miss in August: resource and guide assignment, gear allocation, multi-day and multi-activity itineraries, gift cards, promo codes, waivers, group and private bookings.

Mobile check-in that works on a beach with one bar of signal, and the reporting your accountant already knows how to read.

What you still own after launch

Run migrations, backups, restores, and dependency updates.

Test the critical journey after every model, API, or hosting change.

Monitor failures and fix the edge cases a first prompt will miss.

Maintain every third-party integration as APIs and OAuth rules change.

Risk

High consequence. Use this as a prototype or personal aid. Keep a qualified human and an established provider in the loop for consequential decisions.

Editorial confidence in this assessment: medium. No reviewed project implementation is linked yet.

Generated by Can It Be Vibe Coded? · Full report: https://www.canitbevibecoded.com/fareharbor