Release Notes

Team member revival and invitation reliability fixes — re-inviting a removed teammate now works correctly, accepting the same invitation from two places at once no longer errors, and organization seat-count reconciliation is fully operational

• •Fixed: re-inviting a removed team member now works. When an admin removes someone and later re-invites them, accepting the new invitation correctly restores their membership with the role from the new invitation — instead of failing with an error as before.
• •Fixed: accepting the same invitation from two places at once (two open tabs, or a slow network retry) no longer produces an error for one of the two acceptances. The membership is created exactly once and both attempts complete cleanly — the second one simply confirms the invitation was already accepted.
• •Restored: organization seat-count reconciliation is now fully operational. If a membership change ever fails to sync immediately, a background check corrects the seat count within about 30 minutes.

Organization billing — let your organization pay for one subscription that covers the whole team.

• •Organization billing: an organization can now buy a single subscription that covers the whole team instead of every member paying separately. Admins see a Team section on the billing page where they can upgrade the org's plan; other members see the subscription status read-only.
• •Seat-based pricing: the organization pays for one seat per active member, and the seat count adjusts automatically as members join or leave.
• •Effective tier: your features follow the higher of your personal tier and your organization's tier — for example, an Explorer member of an Adventurer organization gets Adventurer features. If the organization's subscription is past due or unpaid, new invitations and acceptances are paused until billing is resolved (existing members are unaffected).
• •Downgrades are handled through the Stripe billing portal, not the checkout flow — the upgrade flow intentionally supports upgrading or staying on the same tier.

Team settings UI, team invitations, and organization-scoped trips — manage your team from a dedicated settings page, invite people by email, and keep your team's trips private to the org.

• •New Team Settings page at /settings/team — create organizations, view your member roster, manage roles, and send invitations. The page shows all organizations you belong to and lets you create new ones.
• •Organization detail page at /settings/team/[orgId] — view the member roster with roles and join dates, change member roles (admin/member/viewer), remove members, and manage pending invitations. Non-admins see the roster read-only.
• •Last-admin protection: an organization always keeps at least one admin — it is not possible to demote or remove the last admin from the settings UI, protecting your team from accidentally being locked out.
• •Invite your team by email: admins can send invitations from their organization, and invitees accept or decline from a link. Invitations expire after 7 days, and re-inviting someone rotates the link so only the newest one works.
• •Invitees don't need an existing account — accepting an invitation automatically creates their account, adds them to the organization, and signs them in.
• •Invitation management is permission-protected: only org admins can create, list, or cancel invitations, and non-members can't even see the organization exists.
• •Organization trips: trips can now belong to an organization, and organization members can find those trips in their dashboard. Admin and member roles can create and edit org trips; viewers can view them. Org trips stay private — they never appear in the public gallery.
• •Org access automatically follows role: an admin's trips are editable by admins and members, a member's trips are visible to all org members, and viewers can only view. Removing someone from the org revokes their access.

Foundation for team management — the behind-the-scenes building blocks for organizations, members, and roles. No visible changes to your trips, payments, or settings in this release.

• •Organizations now exist as a first-class concept: every account can belong to one or more organizations, and each organization has members with a role — admin, member, or viewer. The person who creates an organization automatically becomes its first admin.
• •Organization management is available through the API today: create an organization, view its members, rename it or set a custom address, change a member's role, or remove a member. Organization settings and invitation flows are being built on top of this foundation and will arrive in upcoming releases.
• •An organization always keeps at least one admin — it is not possible to demote or remove the last admin, protecting you from accidentally locking your team out.
• •This release is internal groundwork: no page changes, no new customer-facing features, and nothing about your trips, subscription, or settings is affected. If you do not use the organization API, you will see no difference.

Behind-the-scenes release reliability — updates are now built and verified directly on the production server before they go live

• •Release builds now run on the production server itself instead of being built elsewhere and transferred in. This removes a whole class of network-transfer and host-capacity issues: there are no more multi-hour builds trying to finish on a saturated machine, and no transfer step that could interrupt a release.
• •Every new version is automatically verified before it is made live — the freshly built application is checked end-to-end (correct image, ports, architecture, and required build settings) and refused if any check fails. A version that doesn't pass every check cannot go live.
• •The automated deploy flow includes an ownership guard and a concurrency guard so releases are never started by a mistaken actor or run on top of each other, then confirms the stack is up and healthy after switching over.
• •These changes are internal: no user-facing features changed, no new data is collected about you, and nothing about your trips, subscription, or settings is affected.

Concierge payment reliability — double-payment protection is now race-free at the database level, larger amounts can be paid online, and abandoned checkouts clear automatically

• •Double-payment protection is now enforced at the database level. If a payment is already in progress or completed for a booking, any further attempt to pay for that same booking is rejected with a clear "This request already has a payment in progress or completed" message — it is no longer possible for a double-click or page refresh to create two payments for the same request.
• •Online payments now support amounts from $0.50 up to $999,999.99, matching the payment provider's own limits. High-value bookings (for example a $15,000+ safari) can now be paid online instead of failing with an error.
• •Abandoned checkouts clear automatically. If you leave a payment page open without completing it — or your session is interrupted — the unfinished payment is automatically cleared once the checkout session expires (typically within 24 hours), so you can simply try again without contacting support. Your payment is never cleared while the checkout session is still active, eliminating any risk of a double charge.
• •If a payment amount is outside the supported range, you'll see a clear message explaining the payable range and asking you to contact your concierge, instead of a generic error.

Concierge payment processing — make one-off payments for confirmed bookings via Stripe Checkout, with status tracking, receipt support, and automatic rate limiting

• •You can now make secure one-off payments for your concierge bookings directly from the chat panel. When a booking is confirmed and requires payment, a "Make a Payment" button appears — click it to open a Stripe Checkout session, complete your payment, and return to Voyonder automatically.
• •Each payment is tracked with a clear status: pending (awaiting payment), processing (payment in progress), succeeded (paid successfully), failed (payment declined or error), or refunded (money returned). You can see the current status and payment history in the concierge chat panel — no more wondering whether a payment went through.
• •A Payment Summary card shows the amount paid, date, payment method (card type and last four digits), and a description of what the payment covers. Refunded payments show the refund amount and date.
• •Payment status badges appear alongside confirmed bookings in the concierge request list, so you can see at a glance which bookings are paid, unpaid, or refunded.
• •Payment receipts are sent automatically via email when a payment succeeds — you'll get a Stripe receipt for every completed concierge payment.
• •Payment history is available: visit any concierge request to see current and past payments. The GET /api/payments endpoint provides programmatic access to your payment records, scoped to your account.
• •Support for card and ACH (US bank account) payments is enabled automatically via Stripe's payment methods. The exact methods available depend on your location and the payment amount.
• •Behind the scenes: payment records are stored in Voyonder's database with Stripe PaymentIntent references for full audit trail and refund support. The stripe-webhook worker handles payment_intent.succeeded, payment_intent.payment_failed, and charge.refunded events to keep payment status accurate in real-time.
• •Rate limiting: payment endpoints are automatically rate-limited to 20 requests per 60 seconds per IP address to protect your account. If you see a "Too many requests" message, wait a few seconds and try again — the limit resets continuously.
• •Checkout reliability: payment status tracking now has a status guard that prevents accidental status reversion. If a payment has been confirmed as successful, it cannot be accidentally reverted to a 'processing' state — giving you more reliable payment status information.

Search-engine optimization for public pages — better titles, descriptions, and sitemap coverage so travelers can find Voyonder more easily

• •The pricing, gallery, and login pages now have page-specific titles and search-engine-optimized descriptions. When these pages appear in search results, they show clear, relevant titles — "Pricing — Voyonder", "Travel Itinerary Gallery — Voyonder", "Sign In — Voyonder" — instead of generic fallback text.
• •The sitemap was updated to include four previously-missing public routes: the Roadmap, Documentation, Release Notes, and the Sample Rome 5-Day itinerary page. Search engines can now discover and index these pages.
• •The gallery page metadata was restructured to fix a build conflict between two export methods — the static export was folded into the existing dynamic generateMetadata function, resolving a compiler error that would have blocked future gallery changes.
• •The login page was refactored into a server/client component split (login form extracted to a client component) to support metadata export alongside the server-rendered authentication flow.
• •These are search-engine-facing changes only — no new user-facing features, no changes to how Voyonder works, no data collected about you, and nothing about your trips, subscription, or settings is affected.

A/B experiments on the pricing page — PostHog-powered testing of CTA placement, tier layout, and social proof to find what works best for travelers

• •The pricing page now runs three PostHog A/B experiments to learn how travelers interact with different designs. Each experiment has three variants with a 50/25/25 traffic split (50% control, 25% variant A, 25% variant B):
• •CTA Button experiment (pricing_cta_button): tests a prominent hero CTA above the pricing cards (hero_cta variant) and a confirmation dialog before checkout (confirmation_dialog variant) against the default CTAs (control). The hero CTA reads 'Start Planning Free' with a lightning icon and 'No credit card required' subtext.
• •Tier Layout experiment (pricing_tier_layout): tests savings badges showing the percentage saved on each tier card (savings_badges variant) and the feature comparison table positioned immediately after the pricing cards (comparison_table variant) against the default 3-card grid layout (control).
• •Social Proof experiment (pricing_social_proof): tests aspirational testimonial cards attributed to 'Beta Tester' / 'Early access program' (testimonials variant) and a metrics band with aspirational statistics and a disclaimer (stats variant) against no social proof (control).
• •All variants default to control — no pricing, layout, or display changes are active for users not in an experiment. Experiment assignment is powered by PostHog and consistent across sessions. The canonical feature-flag architecture uses PostHog as the primary source of truth, with URL/localStorage overrides available only as a fallback for manual QA.
• •Behind the scenes: the feature-flag hook (useFeatureFlag) was rewritten to use posthog-js/react's useFeatureFlagVariantKey as the primary variant source, with Phase 1 localStorage/URL-param flags adapted as a fallback-only QA override layer. A new typed variant configuration module (lib/marketing/pricing-variants.ts) centralizes experiment variant definitions. An idempotent setup script (scripts/setup-posthog-experiments.mjs) can create or verify the three experiments in the PostHog dashboard.

Deploy-safety fix — Stripe payments now work in production; deploy-guard no longer false-positive rejects every deploy

• •Fixed a bug where the Stripe credit-card form could appear blank or fail to load during subscription checkout. The Stripe publishable key was compiling empty in the production client bundle because the build-arg was not wired through to the Docker build. Subscriptions now load and render correctly.
• •The automated deploy-safety guard (Check 8) was refusing every deploy since the release-safety gates shipped in v0.2.22 — the guard checked for build settings in the final Docker image, but those settings only existed in the build stages of the multi-stage Dockerfile. Both stages now declare the same set of build settings, so the guard passes correctly.
• •These are internal infrastructure fixes. No user-facing features changed, no new data is collected about you, and nothing about your trips, settings, or existing subscription is affected. If you experienced a blank checkout form when trying to subscribe, this release resolves it.

Behind-the-scenes release-safety hardening — every deploy is now verified by a fail-closed guard before anything changes, no changes to how you use Voyonder

• •Deploys are now fail-closed: immediately after a new version of the app is built, an automated guard verifies it end-to-end — the right kind of image, the right ports and architecture, and every expected build setting present. If any check fails, the deploy stops automatically before anything on the server is touched. A version that doesn't pass every check simply cannot go live.
• •The pre-release safety checks now run the complete automated test suite — including newer tests for analytics, research, and billing — instead of a fixed list that could silently miss tests added later. More problems are caught before they ever reach the release pipeline.
• •The build settings the app needs are now verified against a single shared source of truth rather than a manually maintained list. If that source is ever unavailable, the release is refused rather than proceeding with possibly outdated settings — fail-closed by design.
• •These changes are internal: no user-facing features changed, no new data is collected about you, and nothing about your trips, subscription, or settings is affected.

Behind-the-scenes Stripe webhook hardening — test-mode events are now handled safely alongside live events, no disruption to your billing or subscription

• •Voyonder's Stripe webhook endpoint now accepts test-mode events using a separate signing secret. This means development and staging environments can send test events to the same endpoint without affecting production billing data.
• •A trust boundary guard ensures that test-mode events are acknowledged but never processed against your account — no accidental subscription changes, no stray billing updates, no side effects from test data.
• •These changes are internal: no user-facing features changed, no new data is collected about you, and nothing about your trips, subscription, or settings is affected. The webhook endpoint continues to work exactly as before for live events.
• •Behind-the-scenes preparation for future pricing experiments — the pricing page now supports feature-flag-driven A/B variants. All variants default to the control experience, so no pricing, layout, or display changes are active. This infrastructure is inert and has no effect on your current experience.

Behind-the-scenes analytics reliability fixes — subscription completion is now reported exactly once, no changes to how you use Voyonder

• •Analytics hardening in preparation for launch: subscription completion tracking was firing twice for new subscribers — it now fires exactly once, from a single authoritative source, so conversion and funnel reporting is accurate.
• •Subscriber identity joining was tightened end-to-end: sessions now carry a stable user ID from their very first page view, and event identity follows the same rules everywhere, so analytics events connect to the right account reliably.
• •These changes are internal: no user-facing features changed, no new data is collected about you, and nothing about your trips, subscription, or settings is affected.

Reliability hardening for subscriptions and research — cleaner errors and a more robust billing upgrade path

• •Subscriptions: fixed a race condition where upgrading during a free trial could strand the new subscription (the webhook guard now correctly distinguishes stale events from genuine promotions using Stripe's timestamps, so your upgrade always lands).
• •Research APIs: invalid search requests now return a clear 400 instead of a generic server error, and semantic search without an embedding provider returns a proper 503. Internal error details are no longer exposed in API responses.
• •These changes are safety and reliability fixes — no new user-facing features, no behavior changes to your trips or billing data.

Behind-the-scenes analytics and release-process hardening — no changes to how you use Voyonder

• •Voyonder's analytics foundation was hardened in preparation for launch: page-view tracking now fires exactly once per page, event identity is stable and correct (your internal user ID is always used for joining analytics events), and analytics configuration is verified automatically before every deploy.
• •The release process gained new safety gates — pre-push checks, automated consistency checks for build configuration, and stricter deploy guards — so future updates reach you with fewer regressions.
• •These changes are internal: no user-facing features changed, no new data is collected about you, and nothing about your trips, subscription, or settings is affected.

Billing portal link fix — no more 500 errors for trial-only accounts, smarter portal routing for every subscription state

• •Fixed a bug where trial-only users (those still in their 7-day free trial) would see a 500 error when trying to access the billing portal from settings. The portal link now uses three-state logic: no subscription routes to settings, trial-only routes to settings, and active subscription routes to Stripe's secure billing portal — every state works correctly.
• •Stripe API errors are now wrapped with user-safe messages — if something goes wrong on the payment provider side, you'll see a clear message instead of a generic error.
• •No action needed from you. Existing subscriptions, trials, and payment methods are unaffected. The portal link continues to work as before for active subscribers.

Conversion tracking on pricing & subscribe flow, plus reliable Stripe billing event processing

• •Voyonder now tracks how travelers move through the pricing and subscription flow — which pages they visit, which CTAs they click, and where they convert or drop off. This helps us understand what's working and improve the experience.
• •New conversion events include: checkout started / completed / failed (with error type), pricing page view, subscribe CTA click, subscription completed, and subscription activated. Events are sent to PostHog (Voyonder's analytics platform) and are visible only to the Voyonder team — never shared externally.
• •Fixed a billing reliability issue where some Stripe events — subscription upgrades, cancellations, trial transitions, and invoice updates — could be silently dropped, so your account didn't always reflect what you paid for. Plan changes now apply reliably and promptly.
• •Added protection against event loss: if a billing event can't be processed, the payment provider is asked to retry it instead of treating it as delivered — nothing is lost in transit.
• •The Discord community link is back in the footer — click the chat icon to join the Voyonder community at discord.gg/m4HZY7xNG3 and connect with fellow travelers.
• •No action needed from you. Existing plans, trials, and payment methods are unaffected; billing continues to work as before. Tracking is product-usage only — no payment card data is ever captured by analytics.

Reliability release — research requests recover automatically, updates deploy without the site going down, and www.voyonder.com redirects correctly

• •Research requests that get interrupted mid-processing — for example during a server restart — now recover on their own. A request never stays stuck in limbo: it is retried automatically and finishes, or the system recovers it on the next cycle.
• •Freshness checks on your gathered references now always run once research completes, so the 'outdated reference' flags stay accurate.
• •Duplicate-reference protection is now scoped per research request, so repeating the same question for different trips can no longer mix up their reference sets.
• •www.voyonder.com now correctly redirects to voyonder.com — if you visited the www subdomain before, you may have seen an error page; that's fixed.
• •Updates are safer: the site now starts on the correct port by default and the background workers retry their recovery sweep with backoff, preventing the temporary outage / restart loop seen after previous deploys.
• •No action needed from you. Existing research requests, trips, and references are unaffected.

Research Artifact Service — natural-language research queries, smarter travel detail recognition

• •Ask Sage research-style questions about your trip in plain language. Requests like 'hotels in Paris under $300 for 4 people' or 'flights to Tokyo in December' are now accepted and processed as structured research queries.
• •Smarter travel detail recognition — Voyonder automatically identifies destinations (airports and cities), dates and date ranges, budget limits, hotels and airlines, activity categories, and traveler counts from what you write, then uses those details to drive research and recommendations.
• •Organized research tracking — each research request gets a status you can check, and the supporting references it gathers are stored and reviewed as a per-trip collection, with automatic checks to flag outdated references.
• •Under the hood: research requests now run through a dedicated pipeline (entity resolution → research planning → reference gathering → freshness verification) instead of being handled ad hoc, which makes results more consistent and faster to refine.
• •Reliability fixes included: research routes are now reachable in production (routing fix), duplicate references are automatically de-duplicated, and a fix for a rare parsing edge case that could stall entity recognition.

Discord community, case studies page, and deploy pipeline resilience

• •New Discord community link in footer — join the Voyonder community at https://discord.gg/m4HZY7xNG3 to share travel stories, get tips, and connect with fellow travelers.
• •New Case Studies page at /case-studies — five draft case studies showcasing real Voyonder travel experiences: solo trip planning, couples getaways, group adventures, experienced travelers, and inspiration seekers.
• •Deploy pipeline hardened — fixed OOM-killed docker load by stopping old containers before loading new images. Added gzip compression for transfers and SSH keepalive to prevent broken pipes during long deployments.

Smarter activity discovery — AI-powered research with curated fallback, no API keys required

• •New discovery sub-agent framework (lib/discovery/) is now the primary activity source. Activities are researched via AI (Claude Haiku) with cache-first performance — previously seen destinations return instantly, new destinations get fresh AI research in ~3 seconds.
• •GYG and Viator provider APIs are now optional enrichment only — when API keys are absent, the route works without them, returning AI-researched activities instead of mock data. When API keys are configured, real pricing and booking links enrich the AI results.
• •Curated fallback activities (City Walking Tour, Local Food & Culture Tour) serve as a last resort when LLM research is unavailable — you'll always see activity suggestions, even without any API keys configured.
• •Route no longer depends on mock data or provider API keys — the app works out of the box with just an OpenRouter key for the AI backend.
• •Activity results include estimated price ranges (no more "Free" surprises), and the route now requires authentication to prevent unauthenticated LLM spend.
• •Destination input validation (length cap + character set filtering) prevents prompt-injection-like payloads, and negative caching skips repeated LLM calls for destinations that have recently failed.

Stripe subscription tier sync hardening — your plan always reflects what you're paying for

• •Fixed a race condition where trial subscribers could be shown incorrect tier information after the trial period ends.
• •Stripe status mapping is now safer and more resilient — handles edge cases like deleted customers and mid-cycle changes.
• •Stale customer references are automatically repaired when detected during login, billing page visits, or webhook events.
• •OAuth redirects now use NEXTAUTH_URL for consistent callback behavior across environments.

Legal page bug fixes — internal metadata stripped from /terms, address placeholder removed from /privacy

• •BUG-1: /terms no longer shows internal workflow metadata (Author/Date/Status header) — the markdown parser now skips lines before the first section heading, showing only the actual Terms of Service content.
• •BUG-2: /privacy Contact section no longer displays a '[company address]' placeholder — the entire Mail bullet line has been removed. Email (privacy@voyonder.com) remains the primary contact method.

Signup checkbox duplicate fix — single terms acceptance checkbox inside the form

• •Fixed a duplicate terms acceptance checkbox on the /join page — the checkbox that was outside the form has been removed, leaving a single, properly-bound checkbox inside the form.
• •The remaining checkbox now uses React state binding (checked/onChange) for reliable form submission and validation.
• •Improved label click behavior (cursor: pointer, select-none) and fixed whitespace/entity encoding issues.

Domain reverted to voyonder.com — canonical domain restored

• •Domain reverted to voyonder.com per CEO directive — the .app migration is on hold.
• •Support email addresses updated to @voyonder.com (support@, legal@, privacy@).

Domain migration to voyonder.app — consistent URLs across the entire site

• •All canonical URLs, Open Graph tags, Twitter cards, and schema.org metadata now use voyonder.app — no more mixed references to voyonder.com.
• •Homepage footer now includes Privacy Policy and Terms of Service links (the inline footer was replaced with the shared component).
• •Under the hood: site URL is configurable via NEXT_PUBLIC_SITE_URL environment variable for future flexibility.
• •DNS setup for voyonder.app is still in progress — app remains accessible via voyonder.com and direct IP during transition.

Privacy Policy, Terms of Service, and customer-facing documentation — legal pages now live

• •New Privacy Policy and Terms of Service pages available at /privacy and /terms — linked from the footer on every page.
• •New customer-facing Documentation page at /documentation with getting started guides, Sage AI tips, subscription info, and troubleshooting — designed for users, not developers.
• •New Release Notes page at /documentation/releases — curated changelog of what's new in each version, written for customers.
• •Sign-up form now requires accepting the Terms of Service before creating an account — checkbox with links to full terms and privacy policy.
• •Footer redesigned with clear links to Documentation, Release Notes, Privacy Policy, Terms of Service, Pricing, and Gallery.

Stripe subscription sync fix — your tier now matches what you're paying for

• •Fixed a bug where some users saw the wrong subscription tier after signing up (e.g., Elite subscribers shown as Adventurer). Your account now correctly reflects your plan.
• •Improved reliability of Stripe customer account linking — stale references are automatically repaired when detected.
• •Subscription tier syncs at login, on billing page visits, and in the Stripe portal — always up to date even if something goes wrong server-side.
• •Behind the scenes: CI/CD pipeline hardened with automated build checks and pre-commit hooks for better reliability.

In-app support chat — get help without leaving Voyonder

• •New support chat widget available on every page after signing in — click the chat icon to ask questions, report issues, or get help.
• •AI-powered support chat can answer common questions and help troubleshoot issues. When the AI identifies a complex problem, it escalates to our team automatically.
• •Support tickets with reference numbers — every conversation creates a ticket you can reference in follow-ups.
• •Knowledge base integration means faster answers to common questions without waiting for a human.
• •New documentation: check /documentation for getting started guides, feature documentation, and troubleshooting tips.

Sage AI reliability improvements — faster responses, better error handling

• •Sage responses now have a 30-second timeout safeguard — if the AI service is slow, you'll get a cached response instead of a hanging spinner.
• •Improved error handling for temporary AI service disruptions — transient rate limits and server errors are handled gracefully without disrupting your planning session.

Sage AI routes fix — chat and model endpoints are now available

• •Fixed a deployment issue where Sage AI chat and model endpoints were returning 404 errors. These routes are now properly included in production builds.
• •Improved health checking — the system now correctly distinguishes between temporary connectivity issues and authentication failures when checking AI service health.

Better health monitoring — real-time system status checks

• •System health checks now validate the AI service provider with a real API key check (not just a network ping).
• •Separate detection for authentication failures, credit exhaustion, and connectivity issues — the health endpoint tells you what's actually wrong.
• •Credit monitoring alerts when AI service credits are running low (under $5 or 90% usage).
• •Fixed an issue that could cause page crashes on certain social media preview generation scenarios.