SetWeave

For group orders placed together with strangers, it's easy to fall out of track. Adjusting prices and finding buyers of less trendy items is also a challenge to managers. This is the game changer.

Comment

Inspiration

Blind boxes and fixed collectible sets create a frustrating mismatch: people usually want one or two characters, while the seller requires someone to buy the complete set. Group orders solve that mismatch by bringing collectors with different preferences together.

I have joined group orders with strangers and organized them for people I barely knew. The hard part was never just finding buyers. Rules were scattered across chat messages, queues were difficult to audit, price changes were easy to misunderstand, and shipping calculations often arrived without a clear explanation. A spreadsheet can store numbers, but it does not preserve consent, sequencing, revisions, or the reasoning behind a final allocation.

I built SetWeave to make those decisions visible. It does not claim to replace trust between people. It gives organizers and participants a shared source of truth so they can judge a group order using the same rules, math, and history.

What it does

SetWeave is the group-order management workspace inside JustMine, a local-first collectible tracking PWA.

Its central workflow turns item-level demand into an explicit whole-set purchase decision:

  • Every queue increment receives a monotonic sequence and append-only history.
  • Live candidate calculations compare demand with complete-set supply.
  • Organizers can inspect allocations, waitlists, leftovers, procurement cost, allocated revenue, and the remaining balance before committing.
  • Finalization creates member and item entitlements and locks the queue.

Around that core, SetWeave provides the supporting workflow needed to operate a real group order:

  • Owner, admin, member, and public-user views with published reservation limits.
  • Pre-release scheduling with an IANA timezone and guarded campaign transitions.
  • Adjustable or fixed pricing, exchange-rate snapshots, exact balance checks, revision history, and participant notifications.
  • Disclosed mandatory and voluntary bundling rules that produce deterministic outcomes without rewriting the original queue.
  • A media studio for converting composite sale images into reusable, provenance-aware item crops.
  • Catalog discovery and independent listing or pricing clones with preserved lineage.
  • Tagged shipment legs split by item count, allocated sales value, or approved net weight.
  • Largest-remainder money allocation so every member share adds back to the exact invoice.
  • Audit history, required-read notifications, IndexedDB persistence, and JSON export and restore.

The demo identity control exposes multiple roles without pretending to be production authentication. The interface also keeps its production boundary explicit: server-enforced authorization, authoritative concurrent queue sequencing, external delivery, object storage, payments, and carrier integrations remain future backend work.

How I built it

The active product is a responsive React 19 and TypeScript PWA built with Vite. Dexie manages a versioned IndexedDB workspace so the golden demo can run without an account or external service. The UI uses GSAP for motivated transitions, Phosphor icons, HTML Canvas for image crops, a service worker shell, and English, Japanese, and Simplified Chinese display modes.

The financial and allocation logic uses integer minor units and deterministic algorithms. Exchange conversion uses parsed decimal rationals and half-up rounding. Shipment fees use largest-remainder allocation for item-count, sales-value, and normalized net-weight bases. This prevents floating-point drift and guarantees that the displayed shares sum exactly to each invoice.

The repository includes a detailed product and system specification, a seeded golden scenario, an English and Simplified Chinese manual, automated unit and component tests, and responsive browser QA. The current vertical slice passes 67 tests across 15 files, TypeScript checking, and the production build.

How Codex and GPT-5.6 helped

I used GPT-5.6 in Codex as a development partner from specification through submission. Codex helped translate lived group-order problems into explicit invariants, role boundaries, state machines, acceptance criteria, and edge-case catalogs before implementation.

During development, Codex worked across the React components, IndexedDB migrations, deterministic allocation algorithms, localization, and tests. It was especially useful for reasoning through money rounding, reservation boundaries, first-come-first-served conflicts, voluntary bundling timeouts, immutable history, and responsive behavior. It also accelerated the synchronized English and Simplified Chinese manuals, browser review, accessibility fixes, and the sentence-level narrated demo pipeline included with this submission.

One of my favorite surprises was discovering that Codex is also an excellent tool for creating instructional demo videos. I did not have time to storyboard, write, voice, capture, and edit one manually, so GPT-5.6 in Codex produced the submitted demo end to end: it selected the story, wrote the English script, built the presentation HTML, mapped every narration sentence to a screen, queued the generated voice clips, and rendered the final video. The result was genuinely wonderful, and I am already applying the same workflow to other work projects.

Playwright remained a lifesaver for loop engineering. Codex could repeatedly build the app, open the real interface, exercise a workflow, inspect the browser console and responsive layout, and capture the next manual checkpoint. That tight build-test-inspect-capture loop made every screenshot and instruction less prone to human error and kept the English and Simplified Chinese manuals synchronized with the product.

The key decisions remained product decisions: fairness must be inspectable, shared catalog facts must not silently couple group policy, finalization must be explicit, and member-impacting changes must append revisions rather than erase history. Codex made it possible to carry those decisions consistently across code, tests, documentation, and the final presentation.

Challenges I ran into

The largest challenge was preserving fairness while supporting realistic exceptions. Admin reservations, forfeitures, replacements, bundling, and voluntary advancement can easily become hidden priority systems. I addressed this by keeping base queue records append-only, publishing limits, linking replacements to released positions, and representing voluntary outcomes as an overlay instead of rewriting history.

Exact financial allocation was another challenge. Count, sales-value, and weight splits all need different bases, but every result must reconcile to a currency invoice exactly. Integer minor units plus deterministic largest-remainder allocation made those calculations explainable and testable.

The local-first demo also needed to be honest about its boundary. A browser-only prototype can demonstrate the full product workflow, but it cannot enforce cross-device concurrency or durable authorization. The UI and documentation make that limitation visible instead of implying a production trust boundary that does not exist yet.

Accomplishments that I am proud of

  • A coherent workflow from campaign setup through queueing, pricing, explicit final allocation, and shipment-fee billing.
  • Deterministic golden vectors that fail fast if queue, allocation, or money results change unexpectedly.
  • Mandatory and voluntary bundling that preserve the original queue and produce inspectable outcomes.
  • A media crop and catalog reuse workflow with provenance and independent clone drafts.
  • 67 automated tests, a passing production build, zero audited dependency vulnerabilities, and responsive QA at desktop and 390 by 844 pixels.
  • Matching English and Simplified Chinese user documentation for the implemented behavior.

What I learned

Transparency is not a single audit-log feature. It must shape the data model, the UI, the calculations, and the lifecycle of every member-impacting change. I also learned that exact money arithmetic is a product experience: people trust a split more when the interface can show why each share exists and prove that all shares add back to the invoice.

The project reinforced the value of specification-first work with Codex. Clear invariants gave GPT-5.6 a stable target and made broad implementation passes safer, while executable golden scenarios caught misunderstandings earlier than visual review alone.

I also learned that the same agentic loop works beyond application code. Codex can turn a running product into a polished instructional artifact, while Playwright can continuously verify that the product, screenshots, and written checkpoints still agree. Together they made documentation and demo production part of the tested delivery process instead of a rushed final chore.

What's next

The next milestone is a real shared backend with account authentication, server-enforced authorization, transactional queue sequencing, idempotency keys, object storage, durable notifications, and tamper-resistant audit records. After that, I would add hosted judge accounts, public campaign discovery, reminder delivery adapters, and production migration from the local IndexedDB prototype.

Built with

react typescript vite dexie.js indexeddb gsap vitest playwright pwa service-worker html5-canvas phosphor-icons codex gpt-5.6

Share this project:

Updates