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."
Where it broke down
“Mostly it just worked. But as I tested the app I started to notice small bugs. When I tapped the input field to type the weight for an exercise, there was no way to dismiss the keyboard. I described the problem to Claude in plain language and it sorted it out immediately.
“The surprise was how conversational the debugging felt. I didn’t need to understand the code to explain what was wrong, and Claude understood the context because it had built the thing in the first place.”
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."
What to try this week
Open Claude Code in plan mode and write down the jobs to be done for a product you actually want to exist. Something you'd use yourself. Let the planner propose the architecture while you focus on the requirements the way Chang did: start from user needs, let the tool handle stack decisions.
Scope it to five sessions of an hour each. Deploy to Vercel or Netlify before the weekend, even if the feature set is thin. The point is a live URL you can send to someone. The moment another person uses what you built, you'll see what's missing in a way no spec could show you.
Questions to sit with
- 01.What product decision are you sitting on right now because the only way to validate it is to build the thing and see?
- 02.If you could test that decision against a working build by Friday, what would you learn that a spec document couldn't show you?
- 03.Chang's hardest problem was defining a single word. What seemingly simple definition in your product would change everything if you got it right?