JourneyPal

JourneyPal began as a case study pitch for a product management certification, where the brief was to find a real pain point and design a product around it. I picked relocation because I had done it, and because the difficulty was easy to describe and hard to locate.

Visa eligibility, timelines, accommodation and country specific regulation are all documented somewhere. The problem is that no two of them live in the same place.

My hypothesis, shaped by having moved, was that relocation stress comes from the lack of centralised, reliable information rather than the process itself being hard.

I ran informal interviews, surveys in Facebook relocation community groups, and focus groups on specific friction points: visas, accommodation timelines, resource fragmentation. The answers kept landing in the same place. Fragmented information, and preparation done by hand.

The proposal served two audiences at once, people relocating and the immigration advisers selling to them, and treated the destination as a variable. That is defensible in a deck and impossible to keep correct in a live product, because the steps that matter are tied to a specific visa in a specific country.

So I cut it in three places. One corridor, New Zealand to Korea, which is the move I have made and can therefore write accurately. One audience, students, whose visa route and timing are consistent enough to write real steps against. One artefact, a thirty item tracker across four phases, instead of a generated document.

Each cut removed something I could not have kept correct, and bought something I could ship. Narrowing is why the thirty steps are right for the people using them instead of roughly right for everyone.

Working alone means nobody argues back, so I put the big calls through a set of Claude Code subagents: a Product Manager, a Critic, a Devil's Advocate and a Synthesizer. It was most useful for testing whether JourneyPal was worth shipping at all and what business model could hold it up. It was not useful for design direction. The method has its own write up.

The free tier holds the five essential pre-arrival items. The full thirty steps unlock for a one time nineteen dollars, and an optional community sits at seven dollars a month after a free first month. None of this has been tested against real willingness to pay.

The split follows the shape of the problem. A move ends, so the tracker is bought once rather than rented. Arriving somewhere does not end, so the only recurring charge is attached to the only thing that continues.

For students moving to Korea, the institutions already do a lot of this. Universities run their own relocation support and much of it is seamless. That does not remove the problem, but it changes who JourneyPal is actually competing with, and I would rather have known it before choosing students as the audience than after.

The second is how far I looked. I researched the Korea route properly and barely looked past it. Visa rules elsewhere turned out to be restrictive enough that adding a second route costs far more than I had assumed. There was also more scattered information than I expected, which is the hypothesis holding up and the workload being worse than the hypothesis implied.

It is live at journeypal.co, built on Next.js and Supabase with Stripe for payment, hosted on Vercel, and the Claude API behind the product's AI.

It is also unfinished, and nobody has signed up. I have not put it in front of anyone, so the pricing above is a set of decisions rather than a tested model, and the research is a finding rather than a validated market. I would rather say that here than let the live URL imply otherwise.

This was my first time building an application with AI coding tools, and I deliberately did not pick one. I ran Codex, Gemini and Claude Code across the same codebase. Slower to build that way, and much faster to learn how each behaves on real work instead of on a demo.

That was as much the point as the product was, and it is the honest reason the product is unfinished. What I came out with was a working method, which is what the next two builds ran on.

Research the market before choosing the audience, and narrow when narrowing is the honest answer, not the disappointing one. Both went straight into the NZ Investment Tracker. I checked the segment was real and sized before designing anything, and built the whole product around refusing to state a number it cannot stand behind.