LOTSPLIT

Split a whole bundle before anyone commits money.

Comment

Inspiration

A seller offers a whole lot: a bicycle, guitar, drill, tent, console and household goods. Several people want different pieces, but a group chat cannot reliably answer the questions that make the purchase possible: is every item allocated, what does each person owe, has everyone accepted the same plan, and did each payment actually complete? LOTSPLIT turns that conversation into one shared, reviewable purchase plan.

What it does

An organizer reviews the catalog and confirms fixed item price shares. Buyers choose preferred items, explicitly acceptable alternatives and a maximum total spend. A deterministic solver finds a complete allocation within those constraints. A larger budget does not increase a buyer's price.

Each buyer accepts their exact items and total. PayPal Sandbox authorization comes later, as a separate decision. The organizer can request captures only when the current plan has all required consents and authorizations. Packing unlocks only when every capture is confirmed complete. A changed plan requires fresh consent; an unknown provider result remains unresolved until checked.

Six fictional 24-item rehearsal examples cover a garage sale, office assets, workshop equipment, vinyl, books and illustrations. Four buyers receive six items each. The free local rehearsal uses clearly labeled payment simulations and sample AI when no key is configured.

How we built it

React and TypeScript provide the organizer and buyer interfaces, with AG Grid Community for structured catalog review. Vite builds the client; Express serves the API and production client. Node.js 24's built-in SQLite stores versioned consent, sessions, plans and payment-operation records.

The PayPal adapter uses Orders v2 and Payments v2 in Sandbox. Nebius runs real NVIDIA Nemotron text and vision inference on the server. Text inference proposes item choices from natural-language preferences; vision proposes catalog entries from a supplied photo. Structured responses are validated and require human review. AI does not set prices, approve a plan or authorize spending. The allocation solver is ordinary application logic. OpenAI Codex assisted development.

Challenges we ran into

The difficult boundary was keeping a plan, a person's consent and a provider's payment result aligned. Consent is tied to exact versioned terms, and payment operations retain their frozen commands and keys so uncertainty does not create a second transaction.

The isolated Sandbox UI run exposed a failed first authorization dispatch for Maja. Its original precise provider error was not retained. After the fix, one explicit guarded recovery reused the original operation, command and key and confirmed a single authorization. Ola, Bartek and Jan had clean normal returns. We kept that recovery distinct from a clean first attempt in the evidence.

Accomplishments that we're proud of

The current public source (93f8570) passes 83 automated tests, TypeScript checks and the production build. Separate real provider evidence confirmed four Sandbox authorizations and four COMPLETED captures of PLN 180, 210, 220 and 230, totaling PLN 840. Packing unlocked for four packages; none was marked packed or shipped. Four sequential application buyer sessions used one Sandbox payer account.

Later checks confirmed an app-triggered PLN 180 Sandbox authorization void and a separate PLN 1 provider-adapter capture/refund. These do not establish a full application compensation/refund UI test. Live webhook delivery remains unverified.

Real Nebius text preferences and a vision proposal from one supplied item image were verified. That vision request did not generate the separately prepared 24-item demonstration catalog. A clean no-key install and persistent rehearsal state were also verified, so reviewers can explore the product without accounts or credentials.

What we learned

A budget is a constraint, an accepted plan is a decision, an authorization is permission to capture, and a completed capture is a provider result. Keeping these states separate makes a group purchase understandable and testable. AI is useful for reducing input work when a person can review the proposal; it should not silently convert a guess into a commitment.

What's next for LOTSPLIT

Complete and test private live-integration judging access, then verify live webhook delivery/signatures and the full application compensation/refund UI paths. The current build focuses on one organizer, one bundle, one buyer group and PLN. Separate buyer transactions do not provide escrow or atomic group settlement; packing and shipping remain manual. A Render Docker Blueprint is prepared, but no hosted deployment is claimed.

Run and review

Free local build and step-by-step judging instructions: https://github.com/Powers-P1/lotsplit/blob/main/docs/judge-access.md . Install Node.js 24, run npm ci, copy .env.example to .env with APP_MODE=rehearsal and blank provider keys, then run npm run dev and open http://127.0.0.1:4319. Choose Garage Sale. No account, payment card or AI key is needed. Rehearsal payments are explicitly simulated; without a key, AI proposals are labeled samples. The public film separately shows genuine PayPal Sandbox evidence and real AI inference. Entrant-provided private live-provider judging access remains pending.

Built With

Share this project:

Updates