Jualokal

Neighborhood secondhand selling with seller-controlled, privacy-safe handovers.

Comment

Jualokal: Making Nearby Secondhand Exchange Convenient

What inspired us

Jualokal started with a simple question: why does selling a used item nearby often feel harder than selling it to someone far away?

In Indonesian cities, people often live close together, but traffic, distance, and coordination make even a short handover difficult. Sellers may not want to arrange delivery, invite strangers to their homes, or spend time negotiating through an online marketplace. Buyers may want affordable secondhand goods, but still need confidence about the item, the person, and the handover.

We imagined a marketplace built around a different assumption: not every secondhand transaction needs shipping. Some items can be inspected and exchanged locally if the process is structured and privacy is respected.

That became Jualokal: a privacy-first marketplace for portable secondhand goods and accountable handovers close to home.

What we built

Jualokal is designed around seller privacy. Sellers publish fixed-price listings, while nearby buyers discover eligible items through privacy-safe map and list views. Buyers see broad distance bands and coarse seller markers, not home addresses, exact household locations, or live movement.

The seller controls the handover. After a successful purchase, the seller selects an outdoor Handover Point and proposes two possible time windows. The buyer can accept a window or request an adjustment. The selected point is revealed for that transaction, while the seller's Home Anchor remains private.

The transaction itself is structured step by step:

  1. A buyer starts a five-minute Checkout Hold.
  2. Successful simulated payment creates an unchangeable Purchase Snapshot.
  3. The purchase amount enters simulated Escrow while the seller payout remains pending.
  4. The seller chooses the Handover Point and proposes windows.
  5. Both parties complete simulated Presence Checks.
  6. The buyer inspects the item against the Purchase Snapshot.
  7. The buyer confirms acceptance and the seller confirms the handover.
  8. Matching confirmations complete the sale, release simulated Escrow, and mark the simulated payout as paid.

We also built recovery paths for problems. A buyer can raise a Material Mismatch if the item differs from the frozen Purchase Snapshot. If the seller contests the claim, the seller keeps the item while simulated Escrow remains held for guided review. The prototype can then demonstrate a simulated buyer refund.

The project includes a fictional, resettable Demo Mode so judges can explore the whole experience without providing a real identity, payment method, or device location. The demo contains fictional buyers, sellers, listings, histories, payments, refunds, and trust outcomes.

How we built it

We built Jualokal as a mobile-first web application using React, TanStack Start and Router, TypeScript, Vite, Tailwind CSS, Supabase, and Playwright.

The persisted foundation includes registration, login, authentication callbacks, protected member pages, sign-out, and member profiles. The richer marketplace transaction flow is intentionally isolated in Demo Mode for this hackathon prototype.

Our team used Codex and GPT-5.6 throughout the build. Codex helped us challenge the original idea, identify ambiguous rules, map dependencies, break the work into bounded issues, implement connected journeys, write boundary tests, and review the result against both the product brief and repository standards.

We recorded the important decisions in a product brief and nineteen decision records. This helped us keep the product coherent as the scope grew. Instead of treating the marketplace as a collection of screens, we treated it as a sequence of states that needed to remain consistent from discovery through checkout, scheduling, handover, confirmation, refund, and reset.

The challenges we faced

The hardest challenge was translating real-world trust into precise product behavior.

It is easy to say that two people should meet safely. It is much harder to define what the application should do when:

  • A seller proposes a meeting point.
  • A buyer accepts a time but later requests an adjustment.
  • One person arrives and the other does not.
  • A buyer claims that the item does not match the listing.
  • One party confirms but the other does not.
  • A payment has succeeded but the handover has not happened.
  • A location check supports eligibility without becoming proof that two people met.

Privacy created another challenge. A marketplace needs enough location information to show nearby opportunities and support a handover, but revealing too much would undermine the product. We therefore separated private Home Anchors, buyer-visible coarse markers, broad Distance Bands, and temporary transaction-specific Handover Points.

We also had to be honest about what the prototype is and is not. The demo simulates payment, Escrow, refunds, identity verification, presence checks, and moderation outcomes. It does not process real money, collect identity documents, track real movement, or represent real marketplace adoption.

What we learned

Our biggest lesson was that the quality of a marketplace depends less on its listing screen than on what happens when the normal path breaks.

The most valuable work was defining boundaries: what is visible, what is private, who is allowed to act next, when money remains held, when a refund is appropriate, and which failures should affect trust.

We also learned that a good prototype can be honest about its limits. By isolating fictional data in Demo Mode and labeling simulated outcomes clearly, we could demonstrate the complete product idea without pretending that unbuilt infrastructure already exists.

Jualokal is still a prototype, but it shows a different possibility for secondhand commerce: local exchange that is convenient for buyers, controlled by sellers, and careful about privacy.

Built With

Share this project:

Updates