indotravellers.co — Audited Migration Plan

What This Project Is

• According to the audit, this is already a substantial travel product.
• It is not a blank domain or a simple brochure site.
• It has OTA-style breadth, AI planning features, auth, itineraries, bookings, and payment-related integrations.

Evidence From The Audit

• site-audit.md says the runtime is a production Next.js app with auth, booking, payment, itinerary, AI chat, and destination models.
• The audit calls out strategy-overbuild as the core problem.
• The main issue is product scope and wedge clarity, not absence of engineering.

Actual Planning Priority

• Narrow the product before migrating architecture.
• The migration plan should preserve useful systems while reducing super-app sprawl.

Sensible Cloudflare Direction

• Cloudflare is still a valid long-term target.
• But this should be treated as a serious application migration, not a generic template rewrite.
• The likely target shape is:
• Pages/Workers for frontend and edge APIs where compatible
• structured data migration only after the canonical source architecture is clear
• reduced feature surface before platform changes

What Should Not Be Assumed

• Do not migrate a “mini Booking.com” stack unchanged just because it exists.
• Do not preserve every booking and payment integration if the wedge is narrower.
• Do not treat the standalone deployment output as the canonical editable architecture.

Implementation Sequence

• Confirm where the canonical source repo lives.
• Choose the real product wedge first: discovery, itinerary engine, affiliate commerce, or something else.
• Remove or defer the broadest operational surfaces that do not serve the chosen wedge.
• Map the retained architecture to Cloudflare-native components only after scope is reduced.

Definition of Done

• The plan reflects that this is an overbuilt but real travel product.
• Product narrowing happens before infrastructure migration.
• Cloudflare migration is scoped to the retained product, not the whole legacy ambition set.

⚙ HARD CONSTRAINTS (enforced for all sites)

This domain MUST operate within these constraints — no exceptions:

• 100% Cloudflare serverless — Workers + D1 + R2 + KV + Workers AI + Vectorize. NEVER PM2, NEVER VPS, NEVER Docker in production path.
• 100% AI-automated — every customer interaction, every moderation decision, every transaction reconcile = AI. No manual queue, no live human chat support, no physical fulfillment.
• 1-operator solo — one person can run the entire operation from a phone. No team meetings, no shared inbox, no shift rotation.
• WhatsApp AI bot for all support (24/7, instant response, no SLA promises that need humans).
• Mayar QRIS for all Indonesian payments (subscription auto-renew, no manual invoicing).
• Indonesian UI primary — bahasa-first, English fallback only where unavoidable.
• Privacy — opt-in only, delete-on-request honored within 24h (cron-driven).
• No physical goods, no inventory — digital products + affiliate referrals only.

If the plan above describes any flow that violates these constraints, treat the plan as ASPIRATIONAL only and rework before building. The constraint trifecta wins.