UseBy

UseBy is a neighbourhood inventory-to-action engine that turns household waste, idle belongings, and hidden local demand into live actions: use, share, borrow, lend, join, reserve, and pick up.

Inspiration

Every neighbourhood is full of invisible waste.

A bag of spinach expires in one flat while someone two buildings away is buying ingredients for dinner. A dress sits unworn for months while another person needs an outfit for one evening. A drill is bought for a single job while the same tool is sitting idle next door. A local bakery has surplus at closing time while nearby households would happily collect it if they knew it existed. Small merchants are guessing what people want, while households are quietly signalling demand through what they search for, save, need, and buy.

The scale of the problem is huge. The UNEP Food Waste Index Report estimates that the world generated 1.05 billion tonnes of food waste in 2022, with households responsible for the majority of it. But food is only one part of the larger pattern: homes are full of underused value, fragmented demand, repeated purchases, wasted goods, and local supply that never becomes visible at the right moment.

Most consumer apps attack one slice of this problem. Food-sharing apps start when someone manually posts surplus. Rental marketplaces start when someone creates a listing. Group-buying tools start when someone organizes a campaign. Surplus apps start from the merchant side.

UseBy starts earlier.

It asks: what if private household inventory, local intent, merchant surplus, and neighbourhood demand could become one live operating system for everyday value?

That is what I built: a product where the database is not just storing listings, but actively modelling the local economy around a household.

What It Does

UseBy turns the things people already have, need, or might waste into specific, useful actions.

A user opens the app and sees a simple consumer experience: what to use soon, what can be shared safely, what can be borrowed instead of bought, what local pools are forming, what surplus merchants have nearby, and what activity is already in motion.

Underneath that calm interface is a live neighbourhood graph.

UseBy understands:

• Groceries: what is on the household shelf, what may expire soon, what needs a label check, what should be cooked first, and what sealed items could safely help someone nearby.
• Fashion: what wardrobe items are idle, what can be lent or rented locally, what might match another person’s need, and how availability windows affect reservations.
• Household goods: tools, appliances, and occasional-use items that are often bought repeatedly but could be borrowed or lent within a trusted local radius.
• Neighbour needs: what nearby households are looking for, when they need it, how far they are willing to travel, and what can be matched without revealing exact addresses.
• Merchant supply: local grocers, bakeries, and shops can publish surplus drops or bid into grouped demand.
• DemandPool: households express unpaid intent for recurring goods, local merchants bid to fulfil that demand, and UseBy scores offers by price, distance, pickup window, reliability, and substitution quality.
• Activity and handoff state: bookings, reservations, merchant pickups, lending requests, handoffs, reviews, and audit events move through explicit state machines.

The core loop is:

1. A household adds inventory, receipt lines, or intent.
2. UseBy writes structured rows into Aurora PostgreSQL.
3. The backend computes action cards, matches, availability, and reservation state.
4. The user reviews a clear action: cook, share, borrow, lend, join, or reserve.
5. A mutation writes back to Aurora transactionally.
6. Activity, proof, trust, and audit state update from current database rows.

The important product idea is that UseBy does not wait for users to browse a marketplace. It surfaces the action that should happen next.

If I have sealed wraps I will not use in time, and someone nearby needs tortillas for dinner, UseBy can turn a private item into a safe local match. If enough households want a Sunday veg bundle, UseBy can turn scattered intent into a merchant opportunity. If a local shop has closing-time surplus, UseBy can expose it as a timed pickup. What would normally become waste, duplicate spending, or invisible demand becomes a working neighbourhood exchange.

How I Built It

UseBy is a full-stack neighbourhood inventory-to-action platform built for the H0 Vercel + AWS Databases challenge.

The frontend is a Next.js application deployed on Vercel. Vercel serves the consumer UI, product flows, route handlers, mutation endpoints, proof pages, and live API surfaces.

The core backend is Amazon Aurora PostgreSQL. I used Aurora as the primary state engine rather than a passive datastore because UseBy depends on live state transitions, proximity, inventory ownership, bookings, trust, auditability, and merchant demand signals.

The Aurora schema models households, users, item instances, grocery inventory, wardrobe and household lending items, needs, matches, bookings, handoffs, DemandPools, merchant bids, surplus drops, reservations, trust events, audit events, job runs, and agent runs.

PostGIS powers neighbourhood radius matching and distance-aware recommendations, so UseBy can match nearby households without exposing exact household coordinates. pgvector and pg_trgm are available for semantic matching and fuzzy relevance where useful, while deterministic business rules remain the authority for safety, eligibility, trust, booking capacity, and payment-related decisions.

The app also includes AWS-ready private file intake through S3 and receipt/label extraction readiness through Textract. Fireworks AI is used for agentic drafting, explanation, item parsing, and review support, but the system deliberately keeps high-stakes decisions deterministic and auditable.

In short: Vercel runs the product experience and server routes, Aurora PostgreSQL holds the live neighbourhood economy, PostGIS makes it local, and the agent layer helps users understand and act without replacing the core rules.

Core technical pieces

Layer	What It Does	Why It Matters
Vercel + Next.js	Hosts the consumer app, route handlers, mutation endpoints, proof pages, and job routes	Judges can use the product directly from a public URL
Amazon Aurora PostgreSQL	Stores households, inventory, needs, matches, bookings, handoffs, pools, merchant bids, store drops, audit events, job runs, and agent runs	The database is the state engine of the product
PostGIS	Computes neighbourhood radius matching and coarse distance	Enables local matching without exposing exact household coordinates
pgvector / pg_trgm	Supports semantic-ready and text-similarity matching	Allows smarter matching while deterministic safety filters remain authoritative
Drizzle ORM	Defines and migrates the schema	Keeps a complex product model maintainable
AWS RDS Data API	Connects Vercel server routes to Aurora	Lets the deployed app mutate live AWS database state
S3 + Textract readiness	Supports private receipt/label ingestion	Builds toward real-world inventory capture without public file exposure
Fireworks AI	Drafts receipt/action-plan outputs for human review	AI helps structure messy input but does not make safety decisions
Agent run persistence	Stores redacted run metadata	Makes AI behavior inspectable for judges and operators
Proof surface	Shows database, extension, provider, job, and audit evidence	Makes the architecture verifiable, not just claimed

UseBy currently has dozens of live API routes across grocery, bookings, lending, demand pools, merchant bids, surplus drops, jobs, notifications, proof, locations, and agents. The production app exposes customer routes for Today, Inventory, Pools, Drops, Activity, Merchant, Proof, and Agent Runs.

The most important engineering decision was to separate input-world seed data from computed product outcomes.

The reset flow can create the neighbourhood, households, merchants, inventory, needs, demand pools, and store drops. But it does not seed final action cards, matches, bookings, reservations, trust events, or pool results. Those are recomputed from Aurora rows. That means the product is not just replaying a scripted UI: the important state is generated by the backend.

For example:

• Action cards are generated from current inventory, expiry observations, package state, and needs.
• Matches are generated from eligible items, open needs, text similarity, PostGIS distance, quantity, urgency, and safety filters.
• Booking and reservation actions write through live route handlers.
• Merchant drops recompute remaining capacity from active reservations.
• DemandPool state depends on current commitments and merchant bids.
• Proof pages read live system state, database extensions, audit events, job runs, and provider readiness.

Challenges I Ran Into

1. Avoiding a static marketplace.
The easy version of this project would have been a pretty listing feed. The harder version was making UseBy compute actions from current database state. I had to model inventory, needs, matches, bookings, handoffs, pools, merchant bids, reservations, audit events, and job runs as connected state rather than isolated screens.

2. Making the database architecture visible without making the UI feel technical.
H0 rewards thoughtful database design, but consumers do not want to see database proof while deciding what to cook. I solved this by separating the product and proof surfaces. The main app is calm and consumer-facing. The Proof and Agent Runs pages exist for judges and operators to verify Aurora, PostGIS, pgvector, job runs, audit events, provider states, and AI guardrails.

3. Safety and privacy.
Food sharing and neighbourhood exchange can become risky if the app exposes too much or lets AI overreach. UseBy keeps exact household coordinates hidden, avoids direct contact details, requires safety acknowledgement, and limits food sharing to eligible sealed/package-safe goods. AI can draft and explain, but deterministic backend rules decide eligibility, visibility, safety, trust, payment boundaries, and reservation capacity.

4. Designing for multiple categories without becoming vague.
Groceries, fashion, household lending, merchant surplus, and group buying could easily feel like five separate products. I tied them together through one shared concept: underused local value. The backend treats them as different expressions of the same neighbourhood graph.

5. Keeping the demo reliable while staying live.
Judges need a working flow, but the product should not rely on pre-baked final outcomes. I built a reset route that clears derived state, restores the input world, then recomputes action cards and matches so the app is ready for a clean recording while still proving that outcomes come from Aurora.

Accomplishments I’m Proud Of

I am proud that UseBy feels like a consumer product on top of a serious backend.

A judge can open the Vercel URL and use the app, but can also inspect the proof surfaces and see that the AWS database is doing real work: PostgreSQL, PostGIS, pgvector, route handlers, job runs, audit events, live counts, and stateful mutations.

I am especially proud of:

• Building a full-stack deployed application with Aurora PostgreSQL as the primary backend.
• Modelling a multi-sided neighbourhood economy across households, merchants, inventory, needs, bookings, pools, drops, and trust.
• Using PostGIS for privacy-safe local matching.
• Creating a reset/recompute flow where matches and action cards are generated from current rows rather than seeded final output.
• Implementing booking and reservation flows that change live state and appear in Activity.
• Adding AI-assisted receipt/action drafting while keeping deterministic rules in control.
• Designing a consumer UI that makes a complex backend feel simple.
• Building proof routes so judges do not have to take the architecture on trust.

UseBy is not a chatbot, not a listing board, and not a static dashboard. It is a small working local economy.

What I Learned

I learned that for this kind of product, the database is not an implementation detail. It is the product.

A real neighbourhood exchange system needs more than users and listings. It needs item state, expiry confidence, package safety, needs, distance, radius, trust, booking state, merchant supply, demand aggregation, auditability, and privacy boundaries. Aurora PostgreSQL was the right choice because the product needs relational modelling, geospatial queries, transaction safety, extension support, and a clear path to scale.

I also learned that AI is most valuable when its authority is constrained. In UseBy, the AI makes messy input more usable: it can draft, normalize, summarize, and explain. But the product is stronger because the boundary is clear. The backend remains the authority on safety, eligibility, capacity, trust, visibility, and payment state.

Finally, I learned that impact products need to lead with usefulness. The user should not feel like they are doing “waste reduction admin.” They should feel like UseBy is helping them save money, eat better, borrow smarter, support local shops, and make their neighbourhood work better.

What’s Next For UseBy

UseBy’s next step is to move from a strong hackathon build into a pilot-ready neighbourhood product.

The roadmap is:

1. Mobile-first onboarding for households in apartment blocks, student halls, and dense communities.
2. Auth and household profiles so real users can join neighbourhoods safely.
3. Receipt and label image upload using private S3 storage and Textract-powered extraction.
4. Richer AI review flows for receipts, labels, household item descriptions, and merchant actions.
5. More advanced semantic matching after deterministic filters pass, using embeddings and reranking for better relevance.
6. Merchant onboarding for grocers, bakeries, dry cleaners, and local shops.
7. DemandPool fulfilment so merchants can bid into real grouped neighbourhood demand.
8. Notifications and reminders for expiry, pickup windows, pool thresholds, and handoff steps.
9. Payments and deposits for future paid rentals, merchant pickups, and reservation guarantees.
10. Trust and reputation loops across completed handoffs, reviews, reports, and repeat interactions.

The larger vision is that every dense neighbourhood should have a live local resource layer: not another feed to scroll, but an operating system for what people already have, what they need, and what nearby merchants can provide.

UseBy makes that local layer visible, actionable, and useful.

Built With

• amazon-aurora-postgresql
• amazon-web-services
• aws-rds-data-api
• aws-textract
• drizzle-orm
• fireworks-ai
• langsmith-ready-tracing
• next.js
• pg-trgm
• pgvector
• postgis
• react
• tailwind-css
• typescript
• vercel