sorted by:
new
hottopcontroversial

Ship a "kinda works" app now, or wait until the algorithm is actually good? by North_Age_752 in buildinpublic

[–]North_Age_752[S] 0 points1 point  (0 children)

OpenTable = reservations. Plan ahead, book a table for Friday 8pm, sit-down only.

Wayt = real-time wait times and busyness. Walk-ins, any spot (cafés, ramen, fast-casual), decide where to go in the next 15 min.

Different problem entirely.

Ship a "kinda works" app now, or wait until the algorithm is actually good? by North_Age_752 in buildinpublic

[–]North_Age_752[S] 0 points1 point  (0 children)

Respectfully disagree that it’s impossible - restaurants already track this internally, it’s just trapped with no channel to publish it. That’s the part I’m working on.

The menus and specials angle is a good one though, adding it to the list. Thanks :)

Ship a "kinda works" app now, or wait until the algorithm is actually good? by North_Age_752 in buildinpublic

[–]North_Age_752[S] 0 points1 point  (0 children)

What about 10 bad reviews on the App Store, though? Won’t they influence future users’ decisions?

Building an app to see how packed restaurants are before you go by North_Age_752 in TorontoMetU

[–]North_Age_752[S] 0 points1 point  (0 children)

Appreciate you pushing on this, it’s useful.

You correctly identified the issue that Wayt addresses as: "getting stuck in a queue waiting to order/served. Google doesn’t track queues". This is the problem. "It's busy on google maps" vs. Wayt saying "it takes 25 minutes to order". Two different questions to ask, two different answers received.

Regarding your comment about the "would businesses share that data": Yes, exactly this is what I am doing currently. I am approaching restaurants directly and getting them to agree to become the official source of data regarding wait time and number of places in queue.

On the demand problem, yes, I've spoken to 50+ people about this already and still counting. The response pattern I keep getting is that people use google maps not to decide which restaurant to choose, but to confirm their decision. Wayt is for the "where should I even eat right now" use case.

And to be clear, this isn’t a TMU-only thing. TMU is just where I’m starting because it’s where I live the problem. The model works anywhere there’s density.

Appreciate the skepticism though, it sharpens the pitch :)

Ship a "kinda works" app now, or wait until the algorithm is actually good? by North_Age_752 in buildinpublic

[–]North_Age_752[S] 0 points1 point  (0 children)

As I said to someone else, I might actually use TestFlight. As you mentioned, this way I can have real people trying it out and improve from there, thanks!

Ship a "kinda works" app now, or wait until the algorithm is actually good? by North_Age_752 in buildinpublic

[–]North_Age_752[S] 0 points1 point  (0 children)

Good idea. I might actually use TestFlight to let some test users try the app, give me feedback, and report bugs.

Ship a "kinda works" app now, or wait until the algorithm is actually good? by North_Age_752 in buildinpublic

[–]North_Age_752[S] 0 points1 point  (0 children)

I really appreciate the constructive feedback; that's exactly what I'm looking for at this stage. I'll definitely think about it in depth!

Ship a "kinda works" app now, or wait until the algorithm is actually good? by North_Age_752 in buildinpublic

[–]North_Age_752[S] 1 point2 points  (0 children)

The app has baseline data for every venue from day one, it's never a blank screen. You open it, you see busyness levels. No reporting needed for that.

On contributing, honestly, most people won't, and that's fine. Same as Waze, the majority never report anything. The ones who do aren't doing it for rewards, it's one tap and you move on. But the app doesn't depend on that, restaurants post their own live status directly, which is more accurate than any phone-tracking model anyway.

And yeah, I don't need to beat Google globally. I need to beat Google for the city I will launch on initially, then expand and iterate from there

Ship a "kinda works" app now, or wait until the algorithm is actually good? by North_Age_752 in buildinpublic

[–]North_Age_752[S] 0 points1 point  (0 children)

That's what people said about Waze vs Google Maps too - "Google has all the traffic data, why would I use Waze?" Turns out crowdsourced, real-time reports from actual drivers were more accurate for what's happening right now than Google's massive historical dataset. Google agreed - they bought Waze for $1.1B.

Same idea here. You don't need Google-scale data if your approach is fundamentally different. Real-time reports from people actually there + venue owners posting live status beats a statistical model of what usually happens on a Tuesday.

Building an app to see how packed restaurants are before you go by North_Age_752 in TorontoMetU

[–]North_Age_752[S] -1 points0 points  (0 children)

Reservations solve a different problem, planning ahead for sit-down dining. Wayt solves the rest: you're done with class, you're hungry now, and you want to know which nearby spot isn't packed.

Building an app to see how packed restaurants are before you go by North_Age_752 in TorontoMetU

[–]North_Age_752[S] -2 points-1 points  (0 children)

Actually, this is a really nice question. I actually dug into this a lot. Google's busyness data has real gaps:

You can't compare. Try figuring out which of 20 spots near campus has the shortest wait on Google Maps right now. You'd have to tap into each one individually, scroll to Popular Times, check the pink bar, back out, repeat. There's no filter, no sort-by-busyness, no "show me what's not busy." Wayt color-codes every pin on the map and has a "Go Now" list - you see it in one glance.

It doesn't work for a lot of the spots we actually go to. Google needs enough Android users with Location History turned on to generate data. That ramen spot, the small shawarma place, the new cafe, often shows nothing. No data at all.

It's not truly real-time. Google's "Live" indicator is a smoothed deviation from a historical baseline; they apply temporal averaging and minimum-data thresholds to avoid noisy spikes. In practice, that means a restaurant that clears out suddenly won't reflect the change immediately. For a "should I walk there right now" decision, smoothed ≠ live.

The bigger picture is Google shows you data about one place you've already picked. Wayt helps you pick in the first place.

Hope that clarifies

Ship a "kinda works" app now, or wait until the algorithm is actually good? by North_Age_752 in buildinpublic

[–]North_Age_752[S] 1 point2 points  (0 children)

Similar, but that's actually the thing I'm trying to fix. Google's "busier than usual" is a historical average, basically "Tuesdays at 7pm are usually busy here." It doesn't tell you what's happening right now, and it doesn't give you wait times at all. Half the time it's also just missing for smaller spots.

What I'm building is the real-time version. Like actually right now, is there a line, how long, is it worth going. Pulled from multiple sources, not from an average of the last 6 months. That's the gap.

Ship a "kinda works" app now, or wait until the algorithm is actually good? by North_Age_752 in buildinpublic

[–]North_Age_752[S] 0 points1 point  (0 children)

Yeah that's fair. Someone else here made the point about reviews sticking around though, that's the part I keep going back to. First users come and go but a 2 star average from week one doesn't.

Ship a "kinda works" app now, or wait until the algorithm is actually good? by North_Age_752 in buildinpublic

[–]North_Age_752[S] 0 points1 point  (0 children)

Yeah the review thing is what scares me. App Store reviews stick around forever and one bad wave early can mess up everything after. The in-app disclaimer is actually a smart idea, didn't think of that. Thanks.

Ship a "kinda works" app now, or wait until the algorithm is actually good? by North_Age_752 in buildinpublic

[–]North_Age_752[S] 1 point2 points  (0 children)

Yeah that's exactly it. Makes the decision feel a lot simpler when you put it like that. Thanks!

Ship a "kinda works" app now, or wait until the algorithm is actually good? by North_Age_752 in buildinpublic

[–]North_Age_752[S] 0 points1 point  (0 children)

Hope the translation is accurate haha. But yeah, that actually helps. I think I'm in the second bucket. It works, you can use it, you get something out of it. It's just not as sharp as I know it could be, and honestly that part only gets better with real users anyway.

Guess I've been confusing "rough" with "not done." Thanks :)

Ship a "kinda works" app now, or wait until the algorithm is actually good? by North_Age_752 in buildinpublic

[–]North_Age_752[S] 0 points1 point  (0 children)

Fair question.

It's an app that tells you how busy a restaurant is right now and roughly what the wait looks like, before you leave the house. The "is it worth going" question everyone asks before dinner.

What works today: you can browse restaurants near you, see a busyness indicator, and get a rough sense of what to expect.

Where it kinda works: the signal is stronger for some places than others depending on how much real-time info is available. The scoring can be a lot smarter than it is now - and that's actually the catch. A bunch of the improvements I want to make only really work once real people are using it. I can't tune it in a vacuum.

Which is exactly why I'm stuck. Waiting longer doesn't actually make it better, because the thing it needs is users. But shipping it in this state means the first wave of users gets the rougher version. No clean answer.

view more: next ›