Borrowly

The problem

Borrowing from neighbours works in spite of its tools, not because of them

Asking to borrow something is a social act held together by group chats, doorbell rings and memory. The person lending has no easy way to say when the item is free, what it costs to borrow, or what happens if it comes back damaged. The person borrowing has no way to compare what is nearby without asking around.

Marketplaces solved this for buying and selling, then borrowed the wrong parts for lending: escrow, guarantees and delivery. I wanted to see what a marketplace looks like when it is honest about being local, social and mostly free.

The bet

Price clarity and location honesty beat a wall of badges

Most of the design work went into two questions people actually ask before they tap: what will this cost me, and how far away is it? Everything else — trust cues, condition, accessories, handover — supports those two answers.

The prototype covers the full loop: discover, item detail, request, confirmation, active borrowing, extension and return, plus an owner-side listing flow.

• Free lending stays first-class: a free listing never shows a fee or a deposit.
• Paid lending charges per borrowing day, using the same date maths everywhere.
• A deposit is always shown separately from the fee, because it is returned, not spent.
• Location is a neighbourhood, never an address — the exact handover point is private until you agree a collection.

The pricing model

One rule, applied everywhere

The daily fee is multiplied by the number of borrowing days, taken from the same date utilities that validate the request. The listing form, item page, request summary, active loan and extension sheet all read from that one calculation, so the numbers can never disagree.

A deposit is a separate line and a separate decision. It is refundable by agreement between the two people, and the interface never implies Borrowly holds or settles it.

Discovery

Neighbourhoods, not one building

The first version assumed Maple House was the whole world. Real borrowing happens across a city: you might walk to the next street but drive to another neighbourhood. Search is therefore a manually chosen area plus a distance tier, matched against the neighbourhood each listing declares.

No location permission is ever requested. There are no coordinates and no invented distances — the model ranks by community, then neighbourhood, then city, and names the area instead of promising a number of metres.

The system

A warm, editorial shell around a practical object

Borrowly deliberately avoids the fintech look. Paper surfaces and a forest-green ink read closer to a noticeboard than a checkout. Fraunces carries headings and prices; DM Sans stays out of the way for everything you have to read quickly.

The component set is small on purpose: one card, one pill, one sheet, one calendar, one price breakdown. Reusing those five things across eight screens is what keeps the prototype coherent at speed.

What I'd do next

The hard parts are the human ones

This is a front-end prototype: one account, local state, no payments and no messaging backend. The other side of a request is automated so the journey can be walked end to end.

The next honest step is not more screens — it is testing whether people will actually charge a neighbour, and whether a refundable deposit reads as fair or as suspicion. Those are research questions, not UI questions.