Inspiration

As individuals who are actively involved in local religious non profit organisation, we have noticed a lot of unnecessary expenditure that results in underutilisation of resources and further costs in storage. For instance, tools are bought at a high price and used once.

We also understand that many of these non-profit organisations are not bothered by the idea of sharing their seldom used resources for the betterment of their community..

So our prototype is a sharing platform, in which organisations can confidently offer to lend, borrow and donate amenities free of charge to other communities in need. This is achieved by hosting a hub where these offers are verified and curated for both donors and acceptors.

What it does

  • Browse and borrow. List what you can spare; see what's near you, nearest first; request it. Requested → approved → collected → returned, one action per stage.
  • Reliability. Both sides rate each other after a loan. Neither sees the other's until both have submitted, so nobody rates defensively.
  • Plan an event with AI. Describe your event, get back what to borrow, from whom, how far away - and what nobody nearby has.
  • Loan agreements. The owner sets a replacement value. The borrower signs before requesting. If something breaks, the owner raises a claim and the borrower accepts or disputes it.

How we built it

Plain HTML/CSS/JS - no build step, no framework, no frontend dependencies. Firebase auth, Firestore and hosting on the free plan. firestore.rules is the real application; everything in the browser is a convenience for honest users.

Free-plan workarounds that turned out better anyway: a bundled 16,090-suburb dataset instead of a geocoding API, canvas-resized data URLs instead of Cloud Storage. The AI planner runs as a local Node server (an API key can't live in browser JS) calling claude-opus-5 with structured outputs.

Challenges we ran into

Firestore rules can't filter a query. During a list, resource.data is empty. That one constraint forced ratings to split across three documents so the blind reveal could work at all.

The planner must not invent inventory. A confident recommendation for a marquee nobody owns is worse than no recommendation. Three layers stop it, and the validator is unit-tested. We threw an impossible brief at it - a 400-person festival wanting a stage and a generator - and got back only real items, with the rest honestly listed as gaps.

A dialog whose promise never resolved. Decline and Cancel had been silently broken since V1. Found by clicking the button, not by reading the code.

Accomplishments that we're proud of

We are proud of innovating a platform built on generosity and grace. In contrast to the increasingly commercialised world, we sought to offer organisations a path to assist one another altruistically and not transactionally.

What we learned

The security rules are the app; everything else is a suggestion. Run the thing - almost every real bug here was found by driving it, not reading it. And naming is a UI bug: "incoming" and "outgoing" describe the direction of the request, but people read them as the direction of the item, which is the opposite.

What's next for ShareSpace

Get the loan terms reviewed by an actual lawyer. Photo evidence at handover. Turn an AI plan into requests in one click. Notifications and live updates. Venues - "who has a hall for 80" is the same question as "who has 80 chairs".

Built With

Share this project:

Updates

Submission history