The Product Decision No Algorithm Could Make
How We Build
Chang Baek is an Experience Director at Fantasy. In five days of spare time between client work, he shipped a live flight deal scoring tool to Vercel using Claude Code. The hardest design problem turned out to be defining what "discounted" actually means.
The problem
Experience directors map user needs, write requirements, and hand specifications to engineering teams who build the thing. By the time anything ships, the person who understood the user best is usually three handoffs away from the code. Chang wanted to find out what happens when the person who writes the jobs to be done also writes the product, on a timeline most teams would spend scheduling a kickoff.
What did you build?
"Farely Honest is a flight deal discovery tool that scores flights against historical pricing data to surface real deals. Most flight search engines show you the lowest price, but that doesn't tell you if it's actually a good price. Farely Honest compares current fares against route averages across multiple time periods, so you can see at a glance when a flight is 30% below what it normally costs. Think of it as a "deal score" for flights.
"Cheapest is such a relative term because usually you have to select the date first then work your way down to find the "cheapest" within the date range you selected. For example, if I'm flying from YYZ Toronto to Seoul in December the cheapest would typically run me $1,750 to $1,900 CAD round trip. But what if I want the real deal regardless of the date? What if there's $1,450 to Seoul in June?"
What made you start building this?
"I started just like how I typically start my design process. I started writing down user JTBDs based on my personal user needs and used plan mode to fill in the blanks. The whole thing, I was only using my spare time in between real work, took about five days with just an hour or two per day prompting, so it was definitely much faster because I basically skipped most of UX and design activities altogether.
"The process I used was based on what Firdosh taught us. Plan mode first: start each feature by having Claude explore the codebase and propose an implementation plan before writing any code. Then AskUserQuestion, where Claude would actually ask me design decisions about trip types, filter options, and UI layout. Then the API integration, component scaffolding with Next.js, React 19, Tailwind, and shadcn/ui, live preview iteration, and Vercel deploy."
How did the pace change the way you made product decisions?
"Because I could see the thing running within hours, I was making product calls based on what I was actually experiencing in the live build rather than projecting from a wireframe. Seeing it and trying it out early makes it extremely useful to find new feature needs. You're testing real interactions, not assumptions about interactions."
What does “debugging through conversation” actually look like?
"Some were just prompting to fix issues as I tested the live experience, and some were just asking Claude to run a QA session on itself. I used Claude's preview server to screenshot, inspect, and refine the UI in real-time. It caught z-index bugs, opacity issues, and savings calculation edge cases all through conversation.
"The most difficult part was to set the appropriate definition of "discounted" price. When I asked it to calculate based on historic average there weren't any results because most flights were more expensive than the last year's historic average. After a bunch of back and forth, ultimately I settled on showing the highest of historical average, per-route max, and per-route average."
How did you handle the Amadeus API?
"Within plan mode, Amadeus API was Claude Code's recommendation and I had to manually sign up for the Amadeus free tier. Setup and connecting the API was fairly straightforward through Claude. I can pull up to 2,000 results with the free plan, and Claude built the deal scoring engine and created a multi-route scanner that compares prices across three time horizons.
"The day after I shipped it, I found out there's more limits to Amadeus than the free 2,000 calls per month quota. There are per-second and per-minute rate limits on top of that, which was a surprise."
What would you do differently if you started over?
"I would've spent more time laying out user stories and requirements in a separate markdown doc before getting right into the build. I spent too much time iterating based on what I saw versus planning this right from the get-go. I think there's a balance though, because you learn things from the live build that you can't learn from a doc. And if I'm doing this for a real business, I would've started with setting up a pricing model first, before building out any of the features."
What would it take to turn this into something you’d seriously maintain?
"Upgrading to the pay-per-use Amadeus plan. Building out plans and pricing, a free tier versus a base plan versus premium. Limiting the free tier usage. Giving users the ability to sign in and save search results and flight deals. And launching social media marketing. I'd start with Instagram, then eventually look into YouTube ads."
How to ship a live product in five days with Claude Code
Write the jobs your users are trying to get done, from your own real need. Chang wrote his own JTBDs and used plan mode to fill the gaps. This front-loads the thinking a spec would.
In Claude Code's plan mode, have it explore the codebase and propose an implementation plan before writing code, and use AskUserQuestion so Claude surfaces real design decisions (trip types, filters, layout) instead of defaulting. Let it scaffold a lean stack; Chang used Next.js, React 19, Tailwind, and shadcn/ui.
If your product needs external data, sign up for the API (Chang used Amadeus' free tier, which Claude recommended) and let Claude build the integration. Check the fine print: Amadeus had per-second and per-minute rate limits on top of the monthly quota, which surprised him the day after launch.
Chang's hardest problem was not code; it was defining what "discounted" means. The tool can compute against any definition, but choosing the one that makes the product honest is yours. Find the equivalent decision in your product and make it deliberately.
Use Claude Code's preview server to screenshot, inspect, and refine the UI in real time, and ask Claude to run a QA pass on itself. That is how Chang caught z-index, opacity, and savings-calculation edge cases.
Push to Vercel or Netlify even if the feature set is thin. The point is a URL you can hand someone: the moment another person uses it, you see what is missing in a way no spec shows.
Frequently asked questions
In this build, Claude Code did the engineering. It recommended and connected the Amadeus API, built the deal-scoring engine, and created a multi-route scanner that compares prices across three time horizons. The decision it could not make was human: what counts as a real discount. When Chang Baek asked the tool to score fares against the historic average, almost nothing qualified, because most flights cost more than the prior year's average. After a lot of back and forth, he defined a discount as the highest of the historical average, the per-route max, and the per-route average. The algorithm could compute against any definition. Choosing the definition that made the product honest was the product decision.
The handoffs disappear, and decisions get made against a running product instead of a document. Normally an experience director writes requirements and hands them to engineers, so by the time anything ships the person who understood the user best is several steps from the code. Because Chang could see his tool running within hours, he made product calls from what he experienced in the live build rather than projecting from a wireframe. His own lesson was that you learn things from a live build that no spec can show you, and that the moment another person uses what you made, you see what is missing.