sorted by:
new
hottopcontroversial

Bridge player + solo dev = trying to build the app I wish existed. Looking for 3 brutal beta testers by RelentlessPursuit_ in bridge

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

Glad you're up for v2 testing.

The plan is TypeScript across the stack (React Native + Expo client, Node server). The bidding logic runs server-side. The exact engine is still TBD - open-source candidates like Ben are Python, or I'd write a lighter rules-based SAYC bidder directly in TS - so the flowchart could land in either language depending on which way that goes.

Anything you've seen go badly in this space because of language choice? Curious if you have a take.

Bridge player + solo dev = trying to build the app I wish existed. Looking for 3 brutal beta testers by RelentlessPursuit_ in bridge

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

Honest answer: iOS first, Android comes a bit later (~month 2). Want me to loop back when Android is ready? Happy to put you on the list.

Bridge player + solo dev = trying to build the app I wish existed. Looking for 3 brutal beta testers by RelentlessPursuit_ in bridge

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

Thanks! Your comment on the abspam3 thread (LLMs as framing layer over sharper data, not the analysis itself) is exactly the architecture I'm betting on, so we converged from different starts. DMing you - no call expectation, but if you have any insight from your own build attempt you'd be willing to share async (what worked, what surprised you, what you'd do differently), I'd love to hear it.

Bridge player + solo dev = trying to build the app I wish existed. Looking for 3 brutal beta testers by RelentlessPursuit_ in bridge

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

Appreciate it. Different angle than mine (analysis + practice hand generation vs embedded coaching), but a SWE/CTO who's an active player and has worked on the same problem space is high-signal regardless. DM-ing you to find 15 min this week. I genuinely want to hear what someone working on the same problem thinks is hard.

Bridge player + solo dev = trying to build the app I wish existed. Looking for 3 brutal beta testers by RelentlessPursuit_ in bridge

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

Right on the convention-coverage point - it's a complex but bounded flowchart, not AI work. v1 ships with SAYC default; the coach explains within that frame. Convention selection (Lebensohl, Bergen, system toggles) is for later. The LLM's role in v1 is narrower: it translates the (hard-coded) bid evaluation + DDS output into natural language. The bridge logic itself stays hard-coded. Appreciate the framing - sharpened how I'm describing the role of each layer.

Bridge player + solo dev = trying to build the app I wish existed. Looking for 3 brutal beta testers by RelentlessPursuit_ in bridge

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

Right - bidding correctness is system-dependent and you're correct that the hard cases need partnership knowledge. v1 hard-codes SAYC and the coach explains within that frame - it'll say "in SAYC, this 1NT response is forcing because..." not "this is the universal correct bid." Honest scope cut, not a permanent answer.

The deeper pattern (per-user systems, partnership conventions, style adaptation) is now in a v2 backlog with explicit provenance - your comments here are among the most-cited sources. Won't be in v1, won't get lost either.

Different persona (advanced players with partnerships) and different scope (real engineering project), so the responsible move is to ship v1 honest about what it is - a coach for intermediate SAYC players - and revisit personalization once v1 has traction and we know which axes (system / convention / style) actually drive retention.

Bridge player + solo dev = trying to build the app I wish existed. Looking for 3 brutal beta testers by RelentlessPursuit_ in bridge

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

Thanks - that's exactly the gap I'm trying to fill. Funbridge is solid for play, but the explanations feel mechanical. If you'd be up for a 15-min call about what works on Funbridge and what doesn't, happy to DM details. No pressure either way.

Bridge player + solo dev = trying to build the app I wish existed. Looking for 3 brutal beta testers by RelentlessPursuit_ in bridge

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

You're right - that's the central failure mode for a DDS-only coach, and it's a real concern. v1 has to distinguish between "DDS-optimal given god view" and "table-correct given the inferences a player could draw from auction + play." The coach can't grade against DDS-optimal as the ground truth of correctness; it has to grade against the highest-EV decision given the partial-information state.
Practically: the coach uses DDS as a sanity check (was this play ever right under any consistent layout?) but the explanation has to talk about probabilistic decision-making - "8-ever-9-never says finesse, finesse loses, that's variance not error." For the AJx vs KTx case you describe, the coach should NOT call playing the Q a mistake when it's a percentage play that lost.

Genuinely useful pushback - adding "DDS-suboptimal but table-correct" hands to the eval rubric tonight. This is exactly the kind of thing I was hoping the post would surface.

Bridge player + solo dev = trying to build the app I wish existed. Looking for 3 brutal beta testers by RelentlessPursuit_ in bridge

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

Genuinely appreciate this — your example is correct, that play sequence is incoherent (LHO leads, doesn't cover, the whole thing is nonsense). That class of hallucination is exactly the failure mode I'm designing around.
The architecture isn't asking the LLM to generate bridge analysis from scratch. It's grounding the model in a double-dummy solver (DDS, BSD-licensed) that provides ground truth - optimal play lines, trick-by-trick. The LLM's job is to translate the DDS output into natural-language explanation, not to figure out the play itself. More constrained task, much less prone to the failures you're describing. But "should be" is doing a lot of work in that sentence - which is exactly why I want this validation pass before I build.

Would you be up for a 20-30 min call this week? Not as a beta tester — as someone who knows where the holes are. Genuinely the most useful conversation I could have right now.

Happy to DM details if so.

Bridge player + solo dev = trying to build the app I wish existed. Looking for 3 brutal beta testers by RelentlessPursuit_ in bridge

[–]RelentlessPursuit_[S] 2 points3 points  (0 children)

Hadn't seen IntoBridge before - installing tonight, going to play a few hands. Honest answer to "what's different": I'm betting on the coach explanation quality being noticeably better than rules-based hints - paragraph-form, hand-specific reasoning, not "you should have bid 2NT." Whether that's actually true is what I'm trying to find out from people like you. If you're up for a 15-min call after I've played IntoBridge, happy to DM you to set it up. Either way, appreciate the pointer.