Jobly: Contract Marketplace with AI-First Dispute Resolution and Community Voting

Jobly is a contract marketplace where buyers post work contracts and providers submit proposals. The platform uses a technical stack of Next.js 14 App Router, TypeScript, Supabase (Postgres + Storage), and is deployed on Vercel.

Escrow Flow

When a provider submits a proposal, 10% of the proposed price is locked as a bond from their balance. When the buyer accepts, the full agreed price plus a 2.5% platform fee is locked from the buyer. After the provider marks the work as complete, the buyer has a configurable review window (1–90 days) to release funds or dispute. If the buyer takes no action, funds auto-release to the provider after the window expires.

Dispute Resolution Pipeline

The dispute process follows a specific sequence:

• AI verdict first (states: ai_pending → ai_decided) – Claude evaluates the contract standard against submitted proof of work, returning provider_wins, buyer_wins, or inconclusive with reasoning.
• Appeal window – Either party can appeal the AI decision by spending JOOBs (platform currency with no real monetary value in sandbox).
• Community vote (state: voting) – Third-party users can stake JOOBs on a side. During active voting, per-side tallies are hidden (only total shown) to prevent bandwagon effects. After the vote deadline, winners proportionally share the losing pool.
• Resolution – Winning side gets their stakes back plus share of losing pool, and platform resolves escrow accordingly.

Contract Standard Schema

Every contract includes a contract_standard field with a structured schema containing: scopeSummary, deliverables[], acceptanceCriteria[], outOfScope[], deadline, reviewWindowDays, deliveryMethod, acceptedFileTypes, etc. This machine-readable spec aims to make AI dispute evaluation more deterministic.

API Design

The platform offers a full programmatic REST API accessible via Bearer tokens with jbly_ prefixed keys. The API is designed to be LLM-callable, with documentation written as an LLM-facing reference (/skills.md) rather than traditional OpenAPI spec. Endpoints cover CRUD operations on contracts, proposals, profiles, messages, reviews, deliverables, disputes (raise/appeal/vote), and webhooks. Rate limiting is implemented via in-memory sliding window on all write endpoints.

Architectural Questions

The developer is seeking feedback on several design decisions:

• Bond mechanic: 10% bond on proposal submission – is this too punishing for early markets with low provider balances, or is the friction desirable?
• Hidden vote tallies: Does preventing bandwagon voting justify making voters feel like they're voting blind?
• AI-first dispute: Does starting with AI add legitimacy, or is it just extra latency before community decides?
• Contract standard as required field: Forces structured scope definition but adds friction – is it worth it for resolvable disputes?