Lets Haggle

Note: This analysis is based entirely on self-reported information from the project description. No independent verification, traction data, revenue figures, customer names, or third-party sources are available.

The description states:

• Let's Haggle adds live, turn-based negotiation to an existing merchant site.
• Owners connect Stripe, import Products and Prices, build an offer, and embed it on their own site.
• Customers open the offer, enter an email, and send a complete proposal.
• Each counteroffer is a new snapshot rather than an edit; both sides see a clear history.
• When one side accepts the other's exact proposal, the system seals that version and either creates a Stripe-hosted Checkout Session or hands the sealed agreement to the merchant’s own payment system.

Inference: The product appears to be a negotiation tool embedded into a website, designed for solopreneurs who want more flexibility in pricing than standard tiered plans allow. It is not a standalone SaaS platform but an integration layer that can be added to existing sites.

The author claims:

• The product fills a gap in subscription pricing where fixed tiers don’t fit every customer.
• Customers often need custom deals, and traditional pricing pages cannot cover combinations.
• Real-time negotiation makes the process more engaging and may improve retention.
• The system allows owners to keep their limits private while enabling structured dialogue.

Inference: The positioning is that of a lightweight, developer-friendly tool for solopreneurs who want dynamic pricing without complex sales processes. It positions itself as an alternative to static pricing pages or full CRM-based negotiation workflows.

The description states:

• Solopreneurs selling software and digital services.
• Customers are those who don’t fit neatly into standard pricing tiers.
• The author notes that “a good customer rarely fits neatly into a pricing tier.”

Inference: The target is small-scale entrepreneurs or freelancers with limited finance teams, likely operating in B2B SaaS or service-based industries where custom pricing is common but not well-supported by existing tools.

The description states:

• The system integrates with Stripe Checkout.
• It supports either Stripe-hosted checkout sessions or handoff to the merchant’s own payment flow.
• No explicit mention of a fee structure for Let's Haggle itself.

Inference: There is no evidence of pricing information, fees, or monetization model for Let's Haggle. The business model appears to be based on integration with Stripe and possibly future monetization via usage-based or subscription fees (not yet described).

The description states:

• Built using Astro, React, Rust, Cloudflare Workers, WebSocket, SQLite, TypeScript.
• Uses event sourcing architecture with WebAssembly compiled Rust running on Cloudflare Durable Objects.
• The system uses a strict execution path: commands → aggregates → events → projections → effects.
• Stripe App integration via Nango and OAuth.
• Clerk handles owner identity; Cloudflare Turnstile guards public session entry.

Inference: The technical stack suggests a modern, scalable, serverless architecture with strong emphasis on reliability and auditability through event sourcing. The use of autonomous coding (Codex) implies a high degree of automation in development, though manual setup remains required for integrations.

The description states:

• Built solo by one person over evenings.
• Submitted to the OpenAI 2026 hackathon.
• No mention of users, customers, revenue, or adoption metrics.
• The author notes that their hypothesis has not yet been tested.

Inference: There is no evidence of traction, user base, or commercial success. This is a prototype or early-stage product with no demonstrated market validation.

The description does not mention any competitors directly.

Inference: No competitive landscape is described. The author implies that current solutions do not adequately support flexible pricing for solopreneurs, but there is no evidence of existing tools in this space.

• No traction or validation: The product has not been tested with real users beyond the founder.
• Single-founder build: The entire project was built by one person, which raises concerns about scalability and long-term maintenance.
• Unproven market demand: The author explicitly states that their hypothesis is untested.
• Limited integration support: While Stripe is supported, there’s no mention of other payment providers or platforms.
• Autonomous coding reliance: Although the use of Codex is highlighted as a strength, it also introduces uncertainty around quality control and consistency.

1. Have you tested this with actual solopreneurs? What feedback did you get?
2. How do you plan to scale beyond the current architecture if usage grows?
3. Are there any plans for multi-tenant support or additional payment integrations?
4. What is your timeline for moving from prototype to a production-ready product?
5. Do you have any existing customers or early adopters who are using this in practice?