MotoTrip Planner

AI-assisted motorcycle routes that favor memorable roads over the fastest arrival.

Comment

Inspiration

I ride motorcycles, but I am also a full-stack developer and founder who spends most of the year building products for other people. That leaves less and less time for planning my own rides.

The frustrating part was never deciding where to go. It was the hours spent combining tools: looking for roads that are enjoyable rather than merely fast, checking interesting stops, estimating fuel and weather, finding accommodation, splitting the route into realistic riding days, and finally getting everything into a GPS.

Most route planners optimize for arrival time. For a rider, that is often the opposite of the goal. I wanted to define the kind of ride I enjoy, let the system do the repetitive research, and keep the final decisions in my hands.

What it does

MotoTrip Planner is an AI-assisted trip planner built specifically for motorcycle riders.

A rider creates a trip with an origin, destination, duration, daily distance, motorcycle, riding style, road preferences, interests, and budget. MotoTrip then:

  • proposes scenic, rider-oriented stops and route ideas;
  • keeps highways, road style, surface preferences, weather, fuel, and budget visible;
  • lets the rider review and edit every proposed stop before saving it;
  • creates a day-by-day itinerary with practical distance and riding-time estimates;
  • suggests points of interest and overnight stays;
  • displays the route on an interactive Leaflet/OpenStreetMap map;
  • exports the confirmed route as a GPX file.

The important design choice is that AI proposes and the rider confirms. Generating a plan never silently changes a trip.

How we built it

MotoTrip Planner is a strictly typed TypeScript application built with Next.js 16, React 19, Tailwind CSS, Zod, Leaflet/OpenStreetMap, Supabase Postgres, and Vercel.

The application uses a domain-first architecture. Business rules live in services, API routes remain thin, and external systems are behind provider interfaces. The OpenAI Responses API produces structured planning suggestions that are validated on the server before reaching the browser. OpenRouteService supplies road routing. If either service is unavailable, deterministic fallback providers keep the core demo usable and testable.

Supabase provides authentication and versioned persistence protected by Row Level Security. The project also includes request validation, ownership checks, rate limiting, health checks, unit and architecture tests, responsive UI, localization, GPX export, and a Capacitor-based mobile shell.

Codex and GPT-5.6 were used throughout the build, not just for the initial scaffold. They accelerated domain modeling, provider boundaries, Supabase security migrations, test design, debugging, UI integration, documentation, and the end-to-end demo workflow. I still reviewed the generated code, made the product and architecture decisions, and verified the result with builds, linting, and tests.

Challenges we ran into

The hardest problem was making an AI-generated route useful without making it unpredictable. Model output cannot be trusted as application state, so we introduced strict schemas, server-side validation, deterministic fallbacks, and an explicit confirmation step.

Routing was another challenge. A straight line between coordinates is not a motorcycle route, but relying completely on an external routing provider would make the demo fragile. Separating routing behind an interface gave us realistic routed previews when configured and a stable fallback when it is not.

We also had to keep trip, stop, itinerary, motorcycle, and profile ownership consistent across Next.js and Supabase. That led to stronger database constraints, Row Level Security policies, optimistic concurrency controls, and focused tests around cross-user access.

Finally, fitting route planning, weather, fuel, accommodation, POIs, itinerary editing, and GPX export into a clear rider workflow required several rounds of simplification and responsive UI work.

Accomplishments that we're proud of

  • A complete flow from creating a ride to generating a plan, reviewing stops, confirming a daily itinerary, and exporting GPX.
  • AI assistance that remains transparent and reversible instead of overwriting user data.
  • A provider-neutral architecture that can switch between deterministic mocks and live OpenAI/routing services.
  • Production authentication and persistence with Supabase Row Level Security.
  • A demo that remains functional without optional paid API credentials.
  • A substantial automated test suite covering domain rules, APIs, routing, security boundaries, and GPX output.
  • A responsive web experience plus the foundation for native mobile delivery.

What we learned

AI features need ordinary software engineering discipline even more than ordinary features: explicit contracts, validation, fallbacks, observability, and user confirmation.

We also learned that the best motorcycle-planning experience is not created by one perfect route score. Riders want to understand the trade-offs and adjust the plan themselves. The useful role for AI is to reduce research and propose coherent options, while leaving taste and safety decisions to the rider.

Working with Codex was most effective when tasks were small, architecture rules were explicit, and every increment ended with verification. It became a development partner for implementation and review rather than a replacement for engineering judgment.

What's next for MotoTrip Planner

Next we want to add live road-quality and closure data, richer accommodation availability, collaborative group rides, route sharing, offline mobile support, turn-by-turn navigation integrations, and learning from rider feedback after completed trips. We will add mobile app and activate booking trought app in 7 days that was hard to achieved.

The longer-term goal is simple: spend less time assembling a trip across five different tools and more time riding it.

Built With

Share this project:

Updates