Inside HiCaptains: A 248-Module Marketplace Teardown
Real numbers from a yacht charter marketplace we shipped: 248 TypeScript modules, 39 database migrations, 3 languages, AI-powered voyage planning. Here's what it actually takes to build a production marketplace in 2026.
Most articles about building marketplaces are written by people who never shipped one. This is not that. HiCaptains is a production yacht charter platform we built end-to-end — search, booking, payment, owner dashboards, real-time chat, and an AI voyage assistant. Below are the actual numbers from the codebase and the decisions we made along the way.
The codebase landed at 248 TypeScript modules at launch. That sounds like a lot until you remember a marketplace has three full surfaces: the guest booking flow, the owner fleet management dashboard, and the admin operations panel. Each surface needs auth, routing, forms, validation, list views, detail views, and modal flows. The number was not the goal; we kept modules small and focused so each one is testable in isolation.
We shipped 39 database migrations from initial schema to launch. Every schema change is a migration file, every migration is reviewed before merge, and every migration runs forward and backward in CI. This is boring infrastructure work that pays for itself the first time you need to roll back a change in production at 2 AM.
Three languages were supported at launch: Turkish, English, and one regional variant. The translation layer is i18next-style key-based, with fallback to English when a key is missing. We do not use auto-translation for production copy — every string is reviewed by a human in each language. The reason is that yacht charter is a high-trust transaction and broken Turkish kills conversion.
The biggest single architectural decision was Supabase Realtime for the concierge chat. Customers ask questions about boats — availability, pet policies, captain experience — and they expect an answer in seconds, not hours. Building real-time chat from scratch with WebSockets and a queue takes weeks. Supabase Realtime gives you presence, message ordering, and reconnection handling out of the box. We integrated it in two days and have never touched it since.
Payments run through Stripe with seasonal pricing rules. A yacht is twice the price in August than it is in November, and the pricing logic has to be transparent to both the owner (who sets the rates) and the guest (who pays them). We model this as a pricing rule engine: each yacht has a base rate and a list of seasonal multipliers, the system applies them at booking time, and Stripe receives the final amount. No manual adjustments, no support tickets about wrong charges.
The AI voyage assistant was the feature that took the longest to get right. The first version was a generic GPT prompt — "plan a 5-day yacht trip from Bodrum to Datça" — and it produced beautiful but useless responses. Itineraries that sent boats through naval exclusion zones, marinas that did not exist, and wind forecasts pulled from 2019. We rebuilt it as a constrained generation pipeline: real marina data from a curated list, real wind windows from a weather API, and the LLM only fills in the human-readable narrative around verified facts. The result is an assistant that produces realistic, bookable itineraries instead of plausible-sounding fiction.
What we did not build: a recommendation engine, a review system with photo uploads, or a mobile app. Every one of those was on the original wishlist, and every one of them got cut because the v1 had to be testable with real users in months, not quarters. The owner dashboard ships with revenue tracking and booking calendars. Reviews and recommendations land in v2.
What this means for anyone planning a similar build: a real production marketplace with payments, real-time chat, and basic AI is a 3 to 5 month project for a small senior team, not a 6 week sprint. The 248 modules and 39 migrations are not bloat — they are the minimum viable surface area for a multi-sided product that handles money. Cut the AI feature if you do not need it. Cut the real-time chat if you can live with email. But do not cut auth, payments, or the owner dashboard, because those are what make a marketplace actually work.
Key Takeaways
- 01A real production marketplace lands at ~250 TypeScript modules across guest, owner, and admin surfaces — not bloat, just the minimum viable surface area.
- 0239 database migrations from kickoff to launch is normal for a payment-handling product. Every migration runs forward and backward in CI before merge.
- 03Supabase Realtime saved weeks on the concierge chat. Building real-time messaging from scratch is a multi-week project; using a managed service is a two-day integration.
- 04AI features need constrained generation, not raw LLM prompts. We rebuilt the voyage assistant to inject verified facts (marinas, weather) and let the LLM only write the narrative.
- 05Realistic timeline: 3–5 months for a senior team, not a 6-week sprint. Cutting AI or real-time chat is fine; cutting auth, payments, or the owner dashboard breaks the marketplace.
Frequently Asked Questions
How long did HiCaptains take to ship?
From kickoff to production launch the project ran on a multi-month timeline typical for a multi-sided marketplace handling real payments. The bulk of the time went to the owner dashboard, payment integration, and the AI voyage assistant — not the guest booking flow, which is the obvious surface but the smallest engineering investment.
Why Supabase instead of a custom Postgres setup?
Supabase gave us managed Postgres, Row Level Security for multi-tenant data isolation, Realtime for concierge chat, and Auth — all from one provider with one billing relationship. Building the equivalent stack from scratch would have added 4–6 weeks of infrastructure work without making the product better.
How did you handle seasonal pricing in Stripe?
We modelled pricing as a rule engine inside our own database, not in Stripe. Each yacht has a base rate and a list of seasonal multipliers; the system computes the final price at booking time and sends that single amount to Stripe. This keeps Stripe simple and gives the owner a transparent UI to edit their seasonal rates without touching code.
What did you cut from the v1 scope?
Three things: a recommendation engine, a photo-uploading review system, and a native mobile app. Each was on the original wishlist. Each got cut because the v1 had to be in front of real users on a real timeline. They are planned for v2 once we have real booking volume to learn from.
Would you build it the same way in 2026?
Mostly yes. The Supabase + Stripe + Next.js stack is still the right call for marketplaces this size. The only thing we would change is starting with the constrained-generation pattern for the AI assistant from day one — we wasted two weeks on a raw LLM prompt before realizing we needed to inject verified facts. Lesson learned, now baked into our default playbook.
Let's discuss your project
15 minutes, no commitment.