CommonCart

Inspiration

Bulk buying can save money, but it often requires more cash, storage, and product than one person needs. For students and nearby households, a good deal can still be out of reach.

We built CommonCart around a simple idea: get the savings of buying together without needing the whole package or fronting everyone else’s money.

What it does

CommonCart connects shoppers who need smaller portions of the same bulk product. Each shopper specifies a quantity, contribution limit, and pickup slot. The app finds compatible groups, divides the package and its cost, and shows each person’s estimated savings.

Shoppers confirm their terms before funding. Capital One’s Nessie sandbox records contributions, returns, and a simulated merchant purchase. Affordability checks account for upcoming bills, a personal cushion, and unresolved outgoing payments.

Our featured demo handles a shopper leaving after contributing: CommonCart returns their contribution, offers the exact share to a replacement, and preserves everyone else’s agreed price. Participants then confirm pickup.

Retail prices are clearly labeled fictional fixtures, and all banking is simulated.

How we built it

We built a single TypeScript application using Next.js and React, with Neon Postgres and Drizzle for persistent application state.

Pure domain functions handle matching, allocation, and money calculations. All monetary values use integer cents, and rounding distributes every penny so contributions add up exactly to the package total.

A server-side adapter integrates with Capital One Nessie to create sandbox accounts, manage bills, record transactions, and read records back for verification. Neon stores sessions, shopping needs, consent, allocations, banking-operation history, and pickup progress. Postgres also powers candidate searches and community insights.

We persist banking operations before dispatching external requests and reconcile uncertain outcomes rather than blindly retrying them.

Challenges we ran into

Coordinating partially completed payments was our biggest challenge. A database rollback cannot undo an external banking request, so we needed explicit operation states, duplicate-request protection, and reconciliation.

Nessie’s observed sandbox behavior also differed from our assumptions: it recorded transactions without changing account balances. We adapted by deriving effective balances from opening balances and confirmed operations, while checking provider records before purchase.

We also encountered authentication and account-access blockers with Snowflake. The current demo uses Postgres analytics and deterministic explanations.

Accomplishments that we're proud of

We completed the funded-dropout journey against the live Nessie sandbox, including contributions, a return, replacement funding, purchase recording, and pickup.

In our fixture scenario, four shoppers divide a 24-roll, $60 package into six-roll, $15 shares. Compared with the fixture’s $22 individual purchase, each saves $7—a total of $28.

We also built a wallet with transaction verification, bill-aware affordability checks, isolated demo sessions, and automated tests covering allocation, duplicate requests, and competing workflow actions.

What we learned

Affordability involves more than an account balance. Upcoming bills, spending limits, and pending commitments all affect what someone can contribute.

We learned to verify external API behavior early and distinguish a recorded sandbox transaction from real settlement. We also learned that handling disruption—especially after someone has paid—is central to making group purchasing useful.

What's next for CommonCart

Next, we want to deploy a hosted pilot, connect authorized retail pricing sources, and validate pickup logistics with real users.

We plan to explore recurring shopping circles, broader product support, and richer analytics once Snowflake access is resolved. Moving beyond the demo would also require real payment processing, retailer checkout integration, and clear fulfillment and refund policies.