Work / 03
AllHere
A peer-to-peer outdoor gear lending marketplace, zero to prototype
Two-sided trust between strangers and thin local supply. Scoping an MVP that could launch small and still feel safe.
- My role
- Technical partner to the founder (acting CTO). I owned technical direction, the borrower and lender flows, the clickable prototype, the landing page, and the iOS architecture.
- Context
- Pre-seed startup. Founder plus me, with customer interviews run by the team.
- When
- Oct 2025 to Feb 2026
- Stack
- 01CoordinatorsOwn navigation, so flows can change without touching views.(built by Jimmy)
- 02Borrower + lender featuresSeparate view models, shipped independently.(built by Jimmy)
- 03RepositoriesOne seam between features and data sources.(built by Jimmy)
- 04Shared servicesMessaging, payments and user management.(built by Jimmy)
01 · Browse
02 · Listing
03 · Deposit + care
04 · Sign in to book
The problem
People own expensive outdoor gear that sits in a garage most of the year. AllHere lets neighbors lend and borrow it. The product problems are classic marketplace ones, with higher stakes: will a stranger bring back your tent, and is there enough gear nearby for a borrower to find anything?
Decisions
1. Let interviews pick the platform
We started with a web build in TypeScript. Customer interviews showed most prospective users were on iPhone, so we went iOS-first and moved to a native architecture.
Tradeoff: a slower first build, in exchange for the platform the first users actually carry.
2. Architecture that lets two products move separately
A marketplace is really two products. I defined MVVM plus Coordinator with a Repository layer, so borrower and lender features could evolve independently while sharing messaging, payments and user management.
3. Trust through photos, not paperwork
Heavy identity verification builds trust and kills conversion. For the MVP, trust came from photo documentation at pickup and return plus reviews, which also backs any claim. Listing review stayed manual.
Tradeoff: less automated fraud protection early, in exchange for a first booking that takes minutes.
4. Cut to what a pilot needs
In-app payments and chat were deferred. Launch was planned hyper-local, so a small area could have enough supply to feel alive.
What I learned
The risk I flagged early is the one every marketplace faces: once two people meet, repeat deals can move off the platform. The prototype was built to make that question testable in a pilot.