I started with one sentence: the best city guide is short, opinionated and made by a human. A month later it was a live product with accounts, a real paywall and a photo of every pick. Here is how.
This is not a framework tutorial. It is how I worked with AI, mostly Claude, like a sharp coworker who has never seen the project. The habits matter more than the tools.
What Whereto is
Whereto answers one question: where should I go right now? Each city gets ten places to eat and ten to drink, with why each made the list and what to order. Near Me re-sorts the picks around you. Three of every ten are free; the rest need a free account.
Where the places come from
Place data comes from the Google Maps Places API. It is paid, and worth it: buying good content (accurate details, hours, photography) frees my time for choosing places instead of describing them. If you are building something similar, budget for data. It is part of the product.
Which places make the ten is another matter. That is Whereto's own selection model, trained on the signals I care about and tuned as the guide grows. It is the secret sauce, so the recipe stays with me.
The stack
- Claude (chat in the app)
- Claude Code
- Claude Design
- ChatGPT
- Refero
- Google Maps Places API
- Python, standard library only
- Static HTML
- Supabase (Postgres)
- Netlify
- An AI site builder, for the first throwaway prototype
Start with a belief, then make its rule unbreakable
I opened a conversation, not an editor. I stated my belief, that a short list from someone with taste beats an endless algorithmic one, and asked Claude to break it: who is it for, who already does it, how does it make money, what is the smallest version that proves it? One sitting produced a brand doc, product requirements, a schema, a pitch and a six-week plan. The name changed later. The belief did not.
A belief hides a rule. Mine: ten picks, no more. So the database enforces it. Ranks run 1 to 10, no two picks share one, and nothing joins a list without something leaving. Every script Claude wrote after that had to respect it, because the database refused anything else.
Here's what I believe: [one sentence].
Before we build anything, argue against it. Who already does this well? Who would NOT want this?
Then name the one rule my product must never break, and show where in the stack it can be enforced so that breaking it is impossible, not just discouraged.
Finish with a one-page product requirements doc, a database schema, and a six-week plan an engineer could start on Monday.Prototype cheaply. Let the evidence cut your scope.
The first plan had four categories (eat, drink, party, do) in a dark, austere iOS app. Reality subtracted. Landmarks and tours were hard to curate to the same standard, so they went, and party folded into drink. Within a day it was eat and drink only.
The look went from black to cobalt and butter yellow, and I went web first: a link can be texted in a second, a beta app cannot. Cities got the same treatment. If one was not good enough, I held it back rather than publish a thin list.
Here's the scope I planned: [scope]. Here's what I've learned from building the first version: [what felt wrong or thin].
Propose the smallest cut that is still true to the belief. For each thing you'd remove, tell me what I lose and what I'd keep as data for later.Design starts with taste, so borrow it from the best
AI will generate a design from one line. It will look fine and feel generic, and it cannot tell you which design is right. That is taste, and you build it by looking at a lot of good work.
So I collect references first. Refero is a searchable library of real, shipped screens: search "city guide" or "sign-in" and see how good teams solved it. Then I study sites I admire and name what I like: type pairing, spacing, photography, restraint.
Use references as direction, not templates. Pick three to five, write one sentence on what works in each, and give those to the AI with the screenshots. "Tight serif headline, quiet interface, one accent colour" beats "make it modern" every time.
Here are [3 to 5] screenshots of sites I admire. For each one, tell me in a sentence what makes it work: type, colour, spacing, photography, tone.
Then tell me what they have in common and what that implies for [my product]. Do not design anything yet.Get a second opinion on your brand, then redesign with it
Once the site was live, I gave ChatGPT screenshots and asked for a brand analysis. A different model has not sat through your decisions, so it reacts like a new visitor. The key phrase is "keep what's working". Without it you get a teardown, not a refresh.
Ok can you analyze my brand on the attached photos from my site wheretoguide.io and provide me a refresh description. Keep what's working, but improve positioning, fonts and colors.I pasted its refresh description into Claude Design and asked for a full redesign. The October 10 refresh brought a new typeface and a sharper line: "Know where to go." The analysis gave direction, the tool gave options, and my taste picked.
Here is a brand refresh description: [paste the ChatGPT output].
Redesign [the landing page] to match it fully: layout, type, colour and tone. Keep [what's working]. Give me the complete redesign, not tweaks.Choose boring technology and let the database be the bouncer
Keep the live parts to a minimum. Every page is a static file, so it cannot be slow or break. The database handles only accounts and the paywall, so locked picks never reach the page, even with JavaScript turned off.
Design this so there is nothing to keep running.
Then assume a reader blocks JavaScript and opens view-source. What can they get? Write a check that fails the build if anything locked leaks.Turn every bug into a check, and give the model ground truth
Every bug gets an automated check so it cannot come back. And when you know something for certain, like exactly where a place is, give it to the model as a hard constraint, not a hint.
We just fixed [bug]. Write a check that would have caught it and show it failing on the old code.
Treat these facts as hard constraints on every lookup: [facts].Keep the voice human
Every pick has two lines: why it is on the list and what to order. They are the product, and the paywall protects them. Claude pulled raw material from real reviews; I wrote from there. The commit log is full of small corrections, including two city intros that a data change had quietly made false.
That is the sneaky failure: change the data and every sentence quoting it can go stale. Anything machine-written is labelled. Anything I stand behind, I wrote.
The data underneath this page just changed: [what changed].
Re-read every sentence on the page that makes a factual claim. Tell me which ones the data no longer supports, quote them, and suggest a fix. Do not change anything yet.Write it down for the next session
Claude does not remember yesterday, so treat each session like onboarding a talented new coworker. I kept a README and an architecture doc in the repository, including the known weaknesses, which is the section a newcomer needs most. It also made an honest privacy page possible: written from what the code does, so the promise and the behaviour cannot drift apart.
Write an onboarding doc for a smart engineer who has never seen this repo. Cover: the shape of the system in one diagram, the three design principles everything follows from, how to build and deploy, and an honest list of known weaknesses.Test with people you trust, then launch with a plan
Before launch I sent friends and family four asks: make an account, browse a city, use it when you are out, and tell me what I got wrong. A feedback form made that one tap. The fixes were unglamorous and important, and most were on phones. Next time I would test on a phone from day one.
For launch I asked for a schedule, not features. Each morning an email brings that day's post: the video, the caption, the hashtags, the time to post and a tracking link. I tap and paste.
Plan a day-by-day launch for [product]: one post per day, each with a theme. For every day, email me a checklist: the asset to grab, the exact caption, hashtags, the best time to post, and a tracking link tagged with the source and the day.Your turn
Seven questions to answer before you build
- What is the one-sentence belief behind this?
- What is the rule my product must never break, and where will the system enforce it?
- What is the smallest version that is still true to the belief?
- What is the least I can make live?
- What would a hostile reader do with view-source?
- What do I know for certain that I can hand the model as a constraint?
- Which parts must stay in my own voice?