Self-initiated · Product design + AI build · 2026 · 11 min read
Ada
Designing a product from a written brief to a live marketing landing page by directing AI tools, with no code written by hand.
Ada is an AI-powered accommodation search built around a simple idea: you should not need hours to find a place to stay. Set filters like interior style or Wi-Fi speed, type what you are looking for into a chat, or get inspired by styles and moods. Ada returns five curated results, each with a reason it was picked. No account needed to start; sign up and it learns your taste over time.
I built it because I needed it. As a digital nomad, searching for a new place every few weeks with no way to filter by aesthetic or Wi-Fi speed is genuinely exhausting. In 2026, I turned the idea into a live, two-page web product by directing AI tools, with the code on GitHub and deployment handled by Vercel.
On naming: in this case study, "Claude" refers to the chat app; "Claude Code" is a separate Anthropic product.
On the prototype: Ada is a live prototype, not a real product. The stay data is mock data. Images are sourced from Pexels. The search does not scrape or connect to Airbnb, Booking.com, or any other platform. Results are served from a local data file. Non-functional features (login, sign-up) are visually present but intentionally inactive.
Research
Finding the problem in the data
The idea for Ada came from my own experience. As a digital nomad, I search for accommodation every few weeks. I had a clear sense of what was missing: a style filter for aesthetics, a real Wi-Fi speed filter, and a way to search by the feeling of a place rather than just its amenities.
Before designing anything, I wanted to confirm whether other travelers felt the same. I searched Reddit and found two threads that answered it directly.
"I spend weeks going through booking sites and comparing to my needs. I wish I could just hop on the web and spend a few hours looking and then booking."
"[I'm] suffering from having too much information."
"I just want to find all the pink themed aesthetic houses. That should be simple considering hosts are titling their Airbnbs."
More from the research
"Whenever I'm planning a trip, it takes me hours to book a hotel."
"I'll scroll through all the photos, and not just the nice ones. I'm hunting for the sneaky shots of the dingy corners, ugly views, or the dreaded bathroom situation."
"Often the one [accommodation] we liked will be booked because we spent too much time looking around."
"Location is also important, as is a modern, clean design. I will not stay anywhere with that outdated dingy bedding and wallpaper."
"[On Airbnb,] a simple 'search for listings with this keyword' function doesn't exist. Literally no way to find a home feature that isn't some material commodity like wifi or a washer/dryer."
The quotes confirmed four distinct pain points, and each one maps directly to a feature in Ada:
| The pain point | Ada's answer |
|---|---|
| The search takes too long | Five curated results instead of hundreds to sift through |
| Too many options cause paralysis | An AI shortlist, with a reason on every result |
| Exhausting manual vetting of photos | Ada reads between the photos to surface the real condition |
| No way to filter by aesthetic | An interior-style filter and mood tiles |
One question emerged from this that mattered more than it seemed. Ada has two separate entry points for browsing: a style filter and mood tiles. The question was: should mood tiles filter by interior style, or by destination type? If by style, they overlap with the style filter and lose their value as a separate entry point. If by destination (Wintry means cold places, Sun-soaked means coastal destinations), they answer a question the filter can't. I resolved it late in the build. Next time I would address it much earlier.
Approach
The experiment
Focus Forest, my other portfolio project, proved I could direct an AI build from a finished design. With Ada I wanted to push further: a larger, two-page product with real search logic, multiple entry points, and a personalization story, started from nothing but a brief.
The question I was testing
Could I take a product concept from a written brief to a shipped, interactive marketing landing page, owning the design and the verification, without writing the code myself?
My goal
A live product on Vercel: a multi-mode search (filters, chat, style, and mood), a five-stay results experience driven by real logic, a preview of how personalization would work after sign-up, a custom design system, and an original brand identity.
Building with AI
A workflow where each tool had a different job
I kept the judgment for myself and let each tool do what it does best:
Claude
Design and product thinking partner before a line of code was written: product strategy, copy drafts, and static HTML reference pages for both screens.
Claude Code
The main builder. It read the static HTML references and wrote the React and TypeScript for the whole product, iterating screen by screen as I directed.
Codex
The second builder, working in the same codebase. I used it for the personalization preview, image sourcing, and a round of refinements. I directed and verified each change.
GitHub & Vercel
Code on GitHub, with deployment handled by Vercel.
Where I sit in the workflow
Different tools at each step, one consistent role. I set the direction, made every design and product call, and verified each output in the browser before moving to the next step.
A prompt framework I developed
I converged on a four-part structure and used it for every meaningful prompt: Role, Context, Task, Outcome. I used it for the opening brief, then switched to short, concrete, single-change prompts for every refinement, sometimes with a screenshot attached when needed to be really clear.
The workflow evolved as I went
I started with Claude Code as the single builder, but it sometimes hit its usage limit mid-session. Rather than wait it out, I brought in Codex as a second builder to keep moving, partly to test whether it could hold its own. It worked great, so it stayed in the workflow, handling the image sourcing via the Pexels open API and the product preview mockup, and further refinements alongside Claude Code.
The build, phase by phase
Phase 01: Brief and exploring
Claude, from a written brief
I started from a written brief, brainstorming the product concept and feature set with Claude. Once this was set, I asked it to create three different landing page layouts based on my input as static HTML references to iterate on. I chose to proceed with a warm cream palette, and for the hero section to show an inline filter card with advanced filter options and a chat input for plain-English prompts. Once the landing page direction was set, I worked with Claude to produce the results page to iterate on.
Phase 02: Building the product
Claude Code, verified in the browser
Claude Code ported the static HTML references into a React and TypeScript build, recreating the full design system as custom styling written from scratch. This phase also built the four entry points (advanced filters, chat box, browse by style, browse by mood), the results page driven by URL parameters, and the matching logic. That logic always returns five stays from any entry point, narrowing by style when the user supplies one, with every card labeled by interior style. The visual result in the browser was where I checked the work, since something could look finished in code and still be wrong until I actually saw it.
A small detail that took several rounds: the styled scrollbar in the WHERE modal was invisible, because native overlay scrollbars auto-hide on macOS Chrome. It took a few passes of explaining the problem and showing screenshots before the AI understood what I meant. The fix: a custom scrollbar built into the DOM, so users always have a cue there is more to scroll.
Phase 03: Personalization preview and content
Codex, with real images from Pexels
I used Codex to source the stay images through the Pexels open API, so every listing had a real, relevant photo rather than a placeholder.
Codex also built the "after sign up" product mockup for the landing page: a taste profile, match scores, and the distinction between liking a stay and saving it. Showing the signed-in experience in the UI proved the personalization promise more concretely than describing it in copy. I also used it for smaller refinements, like the action copy on the style and mood cards.
Phase 04: Interaction polish
Claude Code, tuned until it felt right
The style and mood rows scroll horizontally, so they needed a visual cue that more cards sit off-screen. I added a soft fade at the edge of the row: it sits on the right by default, then moves to the left once the row is scrolled to the end. Because it was built in code rather than dropped in as a fixed image, I could keep adjusting where the fade sat and how strong it was until the row clearly read as scrollable.
Phase 05: Deploy
GitHub (source) · Vercel (deploy)
Once the changes were done and verified in the browser, I committed the project to GitHub and let Vercel handle the deploy, which gave me the live, shareable URL of the prototype.
How I work
Three decisions that show how I work
Throughout the build I stayed in the architect's seat: directing the vision, making the design calls, and verifying every output.
Catching what the AI missed
The AI builds what you ask for. Seeing what the product still needs is the designer's job.
Seeing what the data couldn't
The AI tags from text it can read. Judging what an image actually shows is human.
Showing the promise, not writing it
A mockup says more than a paragraph of copy.
A real example from my workflow
As I added more sections to the landing page, I saw it was getting tall on the mobile version, something the AI never flagged on its own, and I wanted to avoid too much scrolling so the experience stayed comfortable.
I decided to refine the "How Ada works" section on mobile so a user taps through the three steps one at a time, with swipe-to-advance. I pushed the same instinct into the footer, collapsing the columns into a single row on smaller screens.
The AI builds what you ask for. Noticing the problem nobody asked about is the design job.
A real example from my workflow
Codex could tag a stay's mood from the information it could read, like the city, description, structured metadata, and image filename. A stay tagged Wild could check out on all of that, yet the rendered photo might show a city skyline through the window. The text lined up, but the image told a different story. That only became clear when I looked at the actual card, not just the data behind it.
The AI worked from readable signals. Catching what the photo really communicated was a human call.
A real example from my workflow
In its draft, Claude proposed a proof section built on testimonials and never suggested showing the product itself. But testimonials ask the reader to take the promise on faith. I replaced them with a preview of the signed-in experience: match percentage badges, save and skip controls, and an "Ada learned" panel naming the specific taste signals it picked up.
Copy asks a user to read. But most users don't want to read, they want to see.
Honest notes
What worked, what didn't
What worked
- The same short, structured prompts worked across all three tools. Claude, Claude Code, and Codex each followed them reliably.
- With no Figma file to start from, Claude turned a rough concept into working HTML screens in minutes, so I could iterate on the real layout instead of describing it.
- Claude Code built the filter card as working React with live popovers, not a static mockup, so I could test every interaction and tune each one until it behaved.
- Codex pulled real photos for every stay through the Pexels API, turning a tedious manual task into one instruction.
What didn't
- Left to its defaults, the AI added more than I asked for: extra states, options, copy. I kept trimming back to what the product needed.
- On larger changes, it sometimes "fixed" things I hadn't touched, undoing earlier decisions. I caught these by reviewing the whole screen.
- The AI built for desktop and rarely handled mobile. I directed that myself: filters cut off when expanded, a nav that had dropped "Log in."
- Lovable, which I tried first, rendered the search popovers half-transparent, with page content bleeding through. I switched to Claude Code.
The AI will build whatever you describe. Deciding what to describe is the entire job.
What I'd do differently
Review the whole screen after each big change
The AI sometimes changed things I hadn't asked it to touch. I'd build in the habit of reviewing the full screen after each big change from the start, rather than learning that lesson partway through.
Hand the AI mobile criteria up front
The AI built for the desktop view it was shown and never raised mobile on its own. Next time I'd state the mobile requirements (scroll length, what stays in the nav, how filters collapse) from the start, rather than fixing them after.
The interactive prototype
See it running
The experiment worked: a complete, interactive product taken from a written brief to a live URL, designed and verified by me without writing the code myself. It is a deployed, two-page web product: a multi-mode search, a five-stay results experience driven by real logic, a personalization preview, and an original brand identity.
Built on React, TypeScript, and Vite with React Router, and a custom design system written as hand-authored CSS: an ochre and cream palette, with 60 mock stays across 6 interior styles and 5 moods. Stay images are from Pexels. The search returns results from a local data file, with no live API or web scraping.
Reflection
What it demonstrates
Building something I needed kept every decision grounded. When a feature felt arbitrary, I could check it against a real frustration. When copy felt generic, I could ask whether it would have convinced me before I built this. That test was only possible because I was the user, which is why the project stayed honest from brief to build.
What Ada added to my understanding: starting from a brief rather than a finished design changes the workflow significantly. More decisions happen in language before a single screen exists. Getting those early calls right (what the product does, who it is for, what makes it different) determines almost everything that follows. The AI can build quickly from a clear brief. It cannot write the brief for you.
Where I'd take it next
The natural next step is designing the in-app experience for signed-in users: what onboarding looks like, how the personalization surfaces over time, and what the interface shows once Ada has enough signal to make taste-based recommendations.
Looking further ahead, I would love to build Ada as a real product, with live data and actual search results that people can use.