Rally

Inspiration

Planning a group experience asks one person to do several jobs: find a time, understand everyone's requirements, negotiate with the studio, and sometimes pay for everyone before collecting their shares. A spending limit can be private. A casual message can hide the detail that decides whether a plan works.

Rally focuses on friends booking a private pottery session. Its promise is to find a plan that fits their confirmed requirements, then let each person pay their own share. That promise is the product hypothesis; we have not yet validated demand with real groups or studios.

What it does

Each friend saves their available studio dates, private spending limit and essential requirements. The group sees who is ready, without seeing individual budgets or private notes. An optional AI clarification helps resolve wording that could change which session fits.

The demo's consequential example is a friend who says, “I leave Friday.” They might be unable to attend, or they might only be unable to collect their pottery after firing. Rally asks rather than guessing. The participant confirms the meaning. If another friend will collect, the owner nominates that friend and both separately agree to the arrangement and its disclosure.

Confirmed facts go to a deterministic planner. It checks published prices, dates, capacity, capabilities and collection rules against every participant's requirements. It can return no suitable option. It cannot invent a cheaper workshop, relax a private limit or volunteer a collector. In the prepared example, a $50 private limit rules out the $72 wheel workshop while a $48 hand-building session can still fit.

The studio reviews an exact proposal and explicitly reserves its session, including time for setup and cleanup. One approval opens a two-hour payment window and permits settlement when everyone qualifies. Each friend reviews the same frozen offer and approves their own share through PayPal sandbox.

The payment engine confirms a booking only after verifying every required capture. If settlement fails, it refunds completed captures and voids remaining authorizations. An uncertain provider response remains unresolved while Rally checks the original operation; it does not become a success message or a fresh logical charge.

These are implemented prototype behaviors. The full six-friend hosted browser journey is still being verified; the current actual financial proof uses three distinct sandbox buyers through the local service and CLI.

How we built it

Rally uses Next.js and TypeScript for its mobile web app, Supabase managed Auth for verified identities, and PostgreSQL for private preferences, immutable offers, reservations and durable payment operations. The database rejects overlapping reservations for the studio resource.

PayPal Orders v2 creates separate AUTHORIZE orders. Payments v2 captures, voids and refunds them; resource GETs verify provider outcomes and ownership. The webhook receiver authenticates original request bytes and treats a valid notification as a reason to reconcile an existing operation, rather than proof that a booking may confirm.

Astropods supplies server-side model inference using claude-sonnet-4-6 in the recorded evaluation. The model sees the participant's saved note and published studio facts, without private budgets or other friends' details. Its structured output must cite exact source text. Participants confirm proposed meanings; the model has no booking or payment authority. The structured alternative uses the same controls, catalog and planner.

One Render Free web service hosts the app at a custom domain. Existing Supabase Cron invokes bounded payment processing only while work needs attention. The hosted transport has passed idle verification; active recovery after a cold wake remains a release gate.

Codex helped refine the scope, implement the app and payment lifecycle, inspect the UI, and run verification. The recorded tests deliberately weaken safeguards to check that the suite catches failures. Human PayPal approvals remain human actions, and generated demo identities are labeled fictional.

What we verified

Three distinct PayPal sandbox buyers completed a $144 booking, with three verified $48 captures. In a separate fault run, we deliberately canceled one authorization after the first capture: the booking aborted, the $48 capture was refunded, and the remaining authorizations were voided. A third run deliberately dropped a successful capture response and recovered after a worker restart without an additional capture. Saved provider GETs independently checked these results.

The final AI evaluation passed 72 of 72 assessments across 24 authored synthetic cases repeated three times, with zero safety failures. It compares against an independently authored structured baseline and a separate constraint oracle. Earlier failed runs remain available. This is model and planning evidence, not measured user benefit.

The latest local suite passed 123 tests and caught 22 deliberate mutations. Hosted checks have verified HTTPS, private identity scope, judge-role sessions, the scheduler's idle transport and rejection of a forged webhook signature. Genuine signed PayPal webhook delivery and the complete hosted six-buyer flow are still pending.

What comes next

Finish the six-friend browser booking and active hosted recovery recording, then test whether real groups understand the clarification, collection agreement and individual payment flow. Seek a studio's feedback on the two-hour reservation commitment before making real availability claims. The current studio catalog and prepared friends are fictional, and all payments are sandbox payments.

Built With

• astropods
• next.js
• paypal
• postgresql
• render
• supabase
• typescript