GuideMe v2 — Shipped fixes based on your feedback (AI travel companion)
Hey IH 👋
Two weeks ago I shared GuideMe — an AI travel companion (PWA, web-based, free, bilingual Arabic/English) — and got some incredibly useful feedback from this community. Wanted to share what I shipped based on it:
1. Trip countdown / save-to-home reminder 🔔
After generating a trip plan, users now get prompted to set their travel date. A countdown banner appears on the home screen so they don't forget the trip is coming up.
2. Wrong destination bug (this one was embarrassing) 🐛
A user pointed out that when they searched for France, the AI returned results for Athens. Fixed it with:
- A validation layer that checks the AI response against the requested country
- Auto-retry with a stronger prompt if the destination is wrong
- A new city autocomplete that shows the country next to each city
- Gentle inline warning if a user types a city outside their trip's country (but they can still continue if they want)
3. Audio tour Pause/Resume on iOS 🎧
iOS Safari has a known bug where speechSynthesis.pause() is unreliable. Worked around it by canceling the current utterance, tracking the chunk index, and resuming from the same position.
4. Booking links broken (404 errors) 💳
All my Travelpayouts affiliate links had expired. Updated all 8 of them. They were genuinely returning {"error":"not found a link","status":404} — really sorry to anyone who clicked them.
5. Contact / feedback flow 📨
Added WhatsApp + email contact buttons accessible from every screen. Pre-filled greeting messages so people can just type their thoughts and send.
Still on my list:
- The app name. Several of you said "GuideMe" is too generic — I agree, can't find it on Google. Considering a rebrand. Open to suggestions 🙏
- Conversion tracking on Google Ads (currently mis-firing)
- Better onboarding (current bounce rate too high)
Live here: https://guideme7.netlify.app
Would love a second look from anyone who tried v1 — and any new eyes are very welcome too. The feedback has been so much more valuable than I expected. Thank you all 🙏
— Ahmed
Ahmed, the shadow report idea is the one I am still thinking about an hour later. That cleanly solves the chicken and egg problem of how to demonstrate analytics value pre-install. It also reframes the install ask entirely. Right now I am asking site owners to take a risk on adding a widget. That version is asking them to look at a free analysis of data they already have, with the install as the upgrade path. Different sales conversation.
The engagement depth framework is also useful. I had not been thinking carefully about what to actually measure post install. Dwell time, scroll past, return visits on widget pages, all measurable, all leading indicators of whether retrieval is doing real work. Worth building the measurement plumbing into the pilot from day one rather than retrofitting it later.
Will pass both of these to my partners as part of the broader review. They are going to be the kind of inputs that actually shift the roadmap, not just polish it.
Genuinely, thank you. The concession on ICP was generous, and the willingness to push on rigor while doing it is the part I respect most. I will tag you when there is something real to look at, and would be open to a 30 minute call sometime if you ever want to compare notes more directly. No pressure, just an offer.
Tom, this thread has been one of the more useful things I've done as a builder this month, so the gratitude runs both ways.
One small note on the measurement plumbing point, since you're building it from day one: the leading indicator I'd actually weight highest is return visits to widget-containing pages within 7 days. Dwell and scroll past tell you the widget didn't repel them. Return visits tell you it earned a place in their mental model of the site. That's the one that correlates with the trust problem you flagged earlier, not just the quality one.
I'd take you up on the call — not now, but when you have the shadow report prototype or the first pilot data. That's the moment where comparing notes actually has something to compare. Tag me whenever you're at that point and we'll find 30 minutes.
In the meantime, good luck with the partner conversation. Rooting for you to land on something sharp.
Ahmed, the return visits framing is the sharpest of the three metrics and the one I am going to lead with internally. You are right that dwell and scroll past only tell you the widget was tolerated. Return visits is the one that actually answers whether it earned trust. I am going to make sure we instrument that from day one.
The call timing is right. I will tag you when there is something real to compare, whether that is the shadow report prototype or the first pilot data, whichever lands first.
Genuinely appreciated this. Will close the loop when there is something worth closing it on.
This is a great v2 update.
What I like most is that the changes are very concrete. Wrong destination handling, broken booking links, iOS audio behavior, feedback flow. These are the kinds of fixes that make a product feel more real.
The name does feel like the next big bottleneck though. GuideMe explains the category, but it might not be memorable enough for travel.
Curious how you’re thinking about the rebrand. Are you leaning toward something more emotional and travel-specific, or something more functional and assistant-like?
Thanks Wonsik — you're touching something I've been
wrestling with privately.
You're right that "GuideMe" is more category-explanatory
than memorable. Honest reason I haven't rebranded yet:
I'm trying to nail retention first. A great name on a
product people don't return to is just expensive vanity.
When I do rebrand, I'm leaning travel-specific but with
a twist. Most travel apps go for "wanderlust" emotion
(Wandr, Roame). For Arabic-speaking travelers, the actual
emotional anchor is different — it's about confidence in
unfamiliar places, not romance with travel itself. The
name needs to feel like a trusted local friend, not a
Pinterest moodboard.
A few I've been sitting with: Mahjar, Marsool, Buraq,
Khareeta. None feel completely right yet.
If you have intuitions on this — especially how non-English
brands cross over to English markets — I'd genuinely value
your perspective. You picked up on something most commenters
wouldn't.
Curious what you're building?
Ahmed
Really appreciate that — I’ll check out Prompt Helix 👍
The ecosystem angle you’re building is interesting, especially how each tool compounds acquisition for the others.
Curious — which product in the suite is currently driving the most real usage or retention?
Also happy to share more about Tokyo Lore if you’re still open — think your approach could fit well there.
Why this works:
acknowledges them
shows genuine interest (not just pitching)
asks a smart question (keeps convo alive)
softly brings back Tokyo Lore
Thanks for reading. Will check Tokyo Lore.
Ahmed
GuideMe is the bottleneck now.
The product got sharper.
The name still makes it feel generic, replaceable, and impossible to remember.
That matters more in travel than most categories because trust gets priced in before usage does.
People will forgive bugs.
They won’t remember a forgettable name.
You’ve already fixed product issues.
Now fix the part users have to recall later.
aryan_sinh — "trust gets priced in before usage does"
is the most precise framing of my retention problem I've
heard. Saving that line.
You're echoing what another commenter (Wonsik) said earlier
in this thread, almost word-for-word. When two strangers
independently surface the same diagnosis, it stops being
opinion.
Where I'm stuck: the rebrand isn't a naming exercise, it's
a positioning exercise. Most travel apps fight on emotion
(wanderlust, discovery). For Arabic-speaking travelers —
my actual audience — the emotional anchor is different.
It's confidence in unfamiliar places, not romance with
travel itself. The name needs to feel like a trusted local
friend, not a Pinterest moodboard.
Names I'm sitting with: Mahjar, Marsool, Buraq, Khareeta.
None feel completely right yet.
Genuine question back to you: when you've watched founders
That’s exactly the right distinction.
For your audience, I wouldn’t chase “travel inspiration.”
I’d chase trust in unfamiliar places.
So the name should feel less like:
discover places
and more like:
you’ll be okay here
From the names you listed, Khareeta is the clearest functionally, but it may feel too literal. Buraq has stronger myth/energy, but maybe too much weight. Marsool feels closer to guidance/trust, but less travel-specific.
Mahjar feels the weakest to me for this use case.
The frame I’d test is:
trusted local companion for Arabic-speaking travelers
Not “guide app.”
Not “travel discovery.”
More like a calm layer of confidence when someone is unsure where to go, what to do, or who to trust.
That’s the naming lane I’d stay in.
If you end up testing cleaner, more ownable directions beyond the Arabic-native route, I’d also look at names built to carry more trust cross-market. I have a few that fit that lane well if useful.
aryan_sinh — your framing alone shifted how I think
about the product. Saving "a calm layer of confidence
when someone is unsure where to go, what to do, or who
to trust" — that's the cleanest articulation I've read.
On the rebrand: honestly, I'm not ready for that level
of overhaul yet. The technical and emotional cost of
renaming a live product (even a small one) is heavier
than people who haven't done it realize. I'd rather
nail retention first, prove the positioning works under
the current name, and then earn the right to a better
name with the data behind it.
That said — I'd genuinely love to come back to your
offer when I'm there. Some of the best founders rebrand
with intention, not in panic. I'd rather be in the first
camp.
Thank you for the depth here. Real value.
Ahmed
That’s the right way to do it.
Rebranding before the positioning proves itself usually just changes the wrapper.
Rebranding after retention improves turns it into leverage.
Prove the trust layer under GuideMe first.
Then the rename becomes a multiplier, not a gamble.
That’s usually when it’s worth doing properly.
Happy to revisit it when the product earns the sharper name.
Appreciate this, aryan. "Rebrand as a multiplier, not a gamble"
is the line I'm taking with me. I'll bookmark this conversation
and come back when GuideMe has earned the sharper name.
Thanks for the time.
This caught my eye because I am building something adjacent. Mine is a chat assistant that lives on individual content sites and answers visitor questions from that site's own articles. Different bet from yours, where the assistant is a standalone companion that travels with the user.
The destination validation bug you fixed is interesting. I am running into similar grounding problems on a small travel demo site I built (Paris focused, 25 articles), where the assistant occasionally invents details that are not actually in the source content. Sounds like you solved yours with validation plus retry. Curious whether you found that adding validation hurt latency in any noticeable way, or if the user never sees it because the retry only fires occasionally.
Also genuinely curious about the bigger product question. Do you think travelers want one AI travel companion that follows them across destinations, or are they more likely to engage with site specific assistants on the travel blogs they already read? I keep going back and forth on whether these are competing models or complementary ones.
Either way, nice to see someone shipping this discipline. Most v2 posts I see here are vibes. Yours is specifics.
Hey Tom, thanks for the thoughtful comment — and the specifics vs vibes line made my day.
On the validation latency question: yes, it adds roughly 200-400ms when the retry triggers, but in practice users almost never notice it for two reasons. First, the retry only fires on actual mismatches, which is maybe 5-8% of requests in my testing. Second, when it does fire, it's still under 1.5s total, which feels acceptable for an AI response. The bigger cost is API spend on the second call, but I judged that was worth it to avoid the worse user experience of a wrong-country plan.
What I noticed is that the model (Haiku) actually almost never hallucinates wrong countries when the prompt explicitly mentions both the country name AND specific city options upfront. So a lot of the validation might become unnecessary as I improve the prompt structure. Are you using Haiku, Sonnet, or something else for your assistant?
On the bigger product question — I genuinely think these are complementary, not competing. The mental model I'm working with is that site-specific assistants (like yours) win on depth and authority within a known scope, while standalone companions (like mine) win on continuity across the trip lifecycle. A traveler researching Paris hotels probably wants your assistant on a Paris travel blog — it knows the content, the writer's recommendations, the context. But once they're on the trip itself, they need something portable that doesn't require switching between 12 different sites' chatbots.
The real question for both of us might be: do travelers actually distinguish between these contexts, or do they just default to ChatGPT for everything? That's the threat I keep coming back to.
Would love to see what you're building when it's ready — happy to swap notes anytime.
— Ahmed
Ahmed, this is genuinely useful. The 5 to 8 percent retry rate is interesting, I would have guessed higher.
On the technical side, I should flag that my partner handles our stack and I handle the strategy and customer side, so my answers there are higher level. From what I know, we are on GPT-4o for generation and using Qdrant for the retrieval layer. Different ecosystem from yours. Your point about prompt structure preventing the need for validation is good, will pass it along to him.
Curious what made you land on Haiku specifically. Cost, latency, or something about how it handles structured output?
On the ChatGPT threat. I think about this constantly and I am genuinely not sure where it lands. My current working theory is that ChatGPT wins on the obvious factual questions like "what currency does France use" but loses on anything where the user wants opinions, recommendations, or a specific point of view. A travel writer's voice, a chef's actual technique, a DIY person's hard won workaround. Site specific assistants get to lean on that voice. ChatGPT averages it away.
But I am hedging. The honest answer is that I do not know yet whether site owners will agree with that theory enough to want a tool like mine. Your traveler experience suggests the use case for "in trip companion that knows the writer" is real. Less sure about the rest.
Anyway, will absolutely swap notes when the chat widget is live on my demo site. Probably a few weeks out. Will ping you here when it ships.
Thanks Tom — makes sense you're hedging, the thesis is sharp but unproven until site owners price it in.
On Haiku: it was mostly cost and latency. It's significantly cheaper than Sonnet at the volumes I'm hitting (free tier users), and latency matters because the user is actively planning a trip on mobile, often on hotel WiFi. JSON malformation has been rare since I tightened the schema in the system prompt, though I'm still tuning token limits for longer trips.
Your ChatGPT framing is the cleanest I've seen articulated. The opinion vs fact split is real, and I'd add a third axis: ChatGPT loses on anything that requires fresh data ("is this restaurant still open", "what's the visa rule today"). Site-specific assistants and travel companions both have that moat.
Definitely keen to swap notes when your widget ships. Different audiences but overlapping problems.
The fresh data axis is a really good addition. I had been collapsing it into "facts" but you are right that it is its own thing. Static facts (visa rules generally, currency, distance between cities) ChatGPT handles fine. Live facts (is this place open today, what is this week's menu, did the Metro line reopen) it cannot touch without browsing tools, and even then it is unreliable.
Interesting implication: site-specific assistants on travel blogs probably also struggle with live facts unless the site itself is being updated frequently. That is fine for evergreen itinerary content. Probably weaker for restaurant guides where things actually change. Something I will need to think about as I move beyond travel into recipes and DIY.
On Haiku, that all makes sense. Mobile users on spotty hotel WiFi are basically the worst case latency environment, so the Haiku decision tracks.
Will ping you when the widget is up. Realistically a few weeks out, depending on my team's schedule. Appreciate the back and forth, this was genuinely useful for me.
Tom — appreciate the thoughtful follow-up. The recipes/DIY
angle actually amplifies the live-data problem: seasonal
availability, regulatory shifts, supplier changes. Worth
thinking through carefully before you commit there.
On Haiku specifically — landed there for three reasons:
Haiku's response time keeps the conversation feeling alive.
five). Haiku makes that economically viable at my scale.
Haiku reads as warm rather than encyclopedic — subjective,
but it matters when users are stressed in a foreign place.
Sonnet handles the heavier work (multi-day itinerary
generation). Haiku handles the conversational layer.
Your "writer's voice" framing for the ChatGPT threat is the
most precise I've heard. Generic AI averages opinions;
specialized assistants preserve them. That's the moat.
No rush on the widget. Tag me when it ships.
Ahmed
The seasonality point is well taken. I had been thinking of recipes and DIY as evergreen, but you are right that "evergreen content" and "evergreen utility" are not the same thing. A 2019 article about substituting almond flour might still be technically correct but miss that almond flour pricing tripled this year, or that a specific brand discontinued. The site itself does not need to be updating constantly for the underlying world to shift around it.
That actually sharpens my filter. Evergreen content with stable underlying conditions, not just evergreen content. Itineraries to permanent landmarks, fundamental cooking techniques, structural DIY principles. Things that decay slowly because the world they describe decays slowly.
The Haiku reasoning makes a lot of sense, especially the voice point. I had not thought about model output as a tonal choice the way you described it. Worth bringing back to my partner because we have not been thinking about the conversational vs heavy-work split that intentionally.
Quick update since you mentioned the widget. Moved faster than I expected. Just posted my full pitch in Ideas and Validation earlier: https://www.indiehackers.com/post/i-built-an-ai-assistant-for-content-heavy-sites-and-i-do-not-run-a-content-site-myself-honest-feedback-wanted-a16d34f28e.
No pressure to read or respond, just closing the loop on the timeline.
Hey Tom, this is the post I needed to read. I run GuideMe (an AI travel companion — different surface from yours, but same family of problem). Going to answer your three uncertainties with real data instead of opinions, because that is what I would want.\n\nDoes the problem resonate?\n\nYes, but probably not in the shape you are framing it. I have ~5,700 users in 28 days. Average engagement time is 5 seconds. The bounce is not happening because they cannot find the article. The bounce is happening because the landing experience does not earn the next click. So your assistant has to clear two bars, not one: it has to (1) be visible enough to get used at all, and (2) deliver a moment of "oh, this site actually knows what it’s doing" inside the first 5 seconds. The retrieval quality you are obsessing over is bar 2. Bar 1 is whether site owners trust the embed enough to give it real estate above the fold. That is a sales/trust problem, not a technical one.\n\nWhat would make me install it?\n\nHonestly? A clear answer to: "what does my Search Console look like 30 days after I install this?" Because the people who run content sites at scale are obsessed with intent capture, not with chatbots. If your tool can show them "here are 47 questions visitors asked this week that your existing articles do not answer well" — that is a content roadmap they cannot get anywhere else. That is the install trigger.\n\nChat vs analytics — which is the real product?\n\nThe analytics. 100%. The chat is the data collection mechanism. The analytics is the strategic value. I would price it accordingly: chat free or cheap, analytics is where the SaaS lives. You already suspect this — trust the suspicion.\n\nOne more thing on ICP: travel is harder than recipes/DIY for this. Travel queries are seasonal, location-specific, and the affiliate economics are brutal (393 affiliate clicks on my side, 0 bookings, because Booking/Expedia attribution windows are a closed system). Recipes and DIY are evergreen with stable retrieval signals — start there, prove it, then come to travel when you have leverage.\n\nHappy to keep talking. The conversation we already had on the v2 thread shaped how I think about the conversational vs heavy-work split, so this is just returning the favor.”
Ahmed, this is exactly the kind of feedback I needed and I am going to sit with it for a few days before doing anything reactive. Want to review it carefully with my partners before committing to changes.
Let me try to play it back to make sure I have it right.
The two bars framing is the most useful single thing I have heard about this product. I have been operating like the retrieval quality is the differentiator, which means I have been optimizing for an experience that depends on the visitor already deciding to engage. You are saying the harder problem is upstream of that. Whether site owners will give it real estate, and whether the first 5 seconds earn the next click. Both of those are trust problems before they are quality problems.
The "what does my Search Console look like 30 days after I install this" framing is sharp. That is the install trigger, and it is also a much sharper version of what I have been calling the analytics layer. Not "see what visitors ask," but "here is your content roadmap, derived from real visitor intent, that you cannot get anywhere else." That is a different positioning conversation than the one we have been having internally.
On chat vs analytics being the real product, you are pushing on something I have been hedging on. The chat is the visible thing, easy to demo. Analytics is harder to demo because it requires data that does not exist yet for any prospect site. But your framing of free or cheap chat as the data collection layer with paid SaaS for the intelligence makes sense. We need to think about how to demonstrate the analytics value when the prospect has not installed the chat yet.
On ICP, this is where I want to push back gently. Your travel data is from a standalone PWA where the user has to choose to come to you. The affiliate problem you described (393 clicks, 0 bookings, closed attribution windows) is real but specific to that model. An embedded widget on a travel blog with its own affiliate relationships might not hit the same ceiling because clicks go through their existing tracking. That said, your broader point about evergreen content with stable retrieval signals is the right test. Recipes and DIY may genuinely be a better starting point even for embedded widgets, because the content does not decay around the article the way travel content does.
I will bring all of this back to my partners and we will work through it together. Will let you know what we land on.
Genuinely, thank you. The v2 thread feels like it was three days ago and we are already on round four of useful exchange. This is what I was hoping community engagement would produce and was not sure it actually did.
Tom, conceding the ICP point — you are right, standalone PWA attribution is not the same animal as embedded widget on a site with its own tracking. I was generalizing from a narrower data set than I should have.
The one thing I would still test post-install, even on embedded widgets, is engagement depth in the first 30 days: dwell time, scroll past the widget, return visits to widget-containing pages. If those move on stable evergreen content, the affiliate conversion follows. If they don't, retrieval quality is solving the wrong problem.
On the analytics-without-install gap — that is a real chicken-and-egg problem for the demo. Worth thinking about whether you can run a "shadow report" on a prospect's existing GA4 + Search Console data before install. Show them the content roadmap their data is already producing. Install becomes the upgrade to live data, not the cost of entry.
This has been one of the more useful threads I've been part of on IH. Good luck with the partner conversation.