trov
A neighbor-to-neighbor rental marketplace I designed and built end to end. The hard design problem was not the listing flow. It was working out what a marketplace can honestly promise when it holds none of your money, and then keeping that promise on every screen.
One pass through the product: ask the assistant for everything for a birthday party, open one of the items it assembles, pick dates and times, and send the request to its owner. The estimate changes from three days to two when the pickup and drop-off times are set, because the billing model is derived from the actual hours rather than the calendar squares.
Key Contributions
Designed and built the whole product: both sides of the marketplace, the design system, the iOS app, and the Postgres backend behind it.
Decided trov would process no money, then rebuilt the trust model around a shared photo record instead of insurance.
Cut an entire category before beta because it would have attracted the wrong first listings.
Built the paid tiers and shipped them switched off, because a young marketplace dies of thin supply, not of unmonetized hosts.
Designed for App Review as a real user: in-app account deletion, reporting, and blocking were built before submission, not after rejection.
At a glance
Problem
Most people own things they use twice a year, and the neighbor who needs one has no way to find it. The rental apps that exist answer this with deposits, fees, and insurance, which is a lot of apparatus to accept for a $18 drill.
Outcome
A two-sided iOS marketplace in private beta: search and AI-assisted discovery, a full request-to-return lifecycle for both renter and host, and a photo-based trust record standing in for a payment rail.
What I owned
All of it. Product strategy, brand and design system, every screen, the React Native app, the Postgres schema and its row-level security, and the App Store plan.
Constraints
One person and no budget for vendors, which ruled out insurance. Processing no payments was not a limit; it was the decision the rest of the design had to answer for.
The challenge
Lending to a stranger is a trust problem wearing a logistics costume
The mechanics of peer rental are easy. Listings, dates, a request, a handover. What actually stops people is the question underneath: what happens if they wreck it, and who decides?
Every large marketplace answers that the same way. Hold the money, insure the item, arbitrate the dispute. All three need capital, a payments license, and a support organization, and I had none of them.
I spent the first stretch inside the apps that already do this, mostly Yoodlize and the larger rental platforms, looking for what a one-person product could actually copy. The answer was almost none of it: every trust feature they have is a paid dependency, an insurer, a payments processor, an identity vendor, a support team. Rather than build weak versions of all four, I picked the trust signals that need no vendor at all, and made the two positions below the foundation everything else is built on.
The money never touches trov
Holding funds means a license, chargebacks, and a support desk one person cannot staff. Saying so plainly turned the constraint into the pitch: hosts keep every dollar, because there is nothing in the middle to take a cut.
Evidence beats a guarantee
A damage promise needs an underwriter. A timestamped photo record, taken by both people at pickup and return, costs nothing and settles the argument that actually happens, which is what condition it was in.
Design process
The mechanics settled early. The design kept changing.
With no handoff between design and engineering, the loop got very short: a question about a screen could be answered by building it and holding it in my hand the same afternoon. A surprising amount of the design was decided on the device rather than in Figma, and most of what changed came from carrying the phone around and noticing what did not work. Every decision and its reason went into a project file the build is held to, which is why a call made in the first week still holds now.
Settle the promiseBefore any screens: what trov does and does not do with money, damage, and disputes. Everything written in the app follows from this.
Build both sidesRenter and host are one app with two modes sharing one rental record, so whichever side acts first moves the other's state.
Test on a real phoneSimulators hide the failures that matter: thumbs, keyboards over inputs, gestures colliding with navigation.
Write the reason downEach revision recorded with why, including the ones that were tried and rejected, so nothing gets re-argued.
The home screen, three times
The first version was a plain feed. The second put listing photos behind everything as a frosted mosaic, with a bright teal accent and a serif display face, and it had a legibility problem no amount of tuning fixed: text sitting on a variable backdrop has no single gray that reads everywhere. I mocked up three directions on the real screen and chose the one that owned a color instead of borrowing one from the photos. The result is a deep ink-teal ground for the tab destinations, a light sheet the content scrolls on, and solid white cards so the photography is the show. That became a rule for the whole app: tab roots wear the brand, pushed screens are plain work surfaces.
A system small enough to hold in your head
One accent family, not two. The bright teal that started as the brand color was retired once the ink ground arrived, because a mix of light and dark teals read as inconsistent rather than considered. On light surfaces the accent is the ink; on the ink ground it is a pale teal. The display face went from Inter, to a serif I lived with for two weeks and did not love, to Bricolage Grotesque, and it is reserved for what the app says in its own voice: screen titles, the wordmark, the hero line. Listing titles and people's names stay in Inter. The brand gets a voice; the content does not get dressed up in it.
What the phone kept correcting
Forty-eight recorded rounds of revision, most of them my own hands on a real phone, and one round that came back from the first TestFlight build on other people’s devices. Each was a list of things that were fine on a laptop and wrong in a hand. A few changed the design rather than merely fixing it:
The calendar stopped asking questions. Picking a single day used to take a double tap, and a By day / By hour toggle sat above the grid. Both confused people. Now one tap selects a day, a second later tap extends it, and the billing model is derived from the dates and times rather than chosen. A whole class of validation errors disappeared because the model changed, not because the copy got clearer.
Names testers tripped on got renamed. Home became Search, because the screen is about finding things. Rentals became Renting, because Rentals read as either side's stuff. The condition photos at each end of a rental were called check-in and check-out until it was clear one word was doing two jobs, so the shared record is the Handoff and the start of a rental is the Pickup.
A swipe should never also be a tap. Releasing a swipe-to-cancel gesture was opening the row underneath it. The fix is a small guard that remembers which rows are mid-swipe, and it is now the rule for anything swipeable that sits on something tappable.
The row owns the tap, not the switch. The Instant book setting had a label people tapped and a switch that was the only tappable thing. Making the row the control and the switch a readout is the pattern every switch row follows now.
Never hand-draw brand geometry. The launch animation was rebuilt five times. Every version with a hand-drawn treasure chest read as amateur no matter how the coordinates were tuned. The one that works draws the real icon glyph on and lets it settle. Mockups on a web artifact came first; native code came after the mockup was approved, and that order is now the rule for brand motion.
The product
Four screens that had to carry it
Two of these are where the trust model met a real screen and had to stay honest under pressure. The other two are the problem every young marketplace has: a catalog thin enough that one empty search loses the person for good.
Decisions and tradeoffs
Five calls that shaped the product
With no team to argue against, the discipline had to come from writing the reasoning down and living with it. These are the ones that cost the most to hold.
Considered
Holding payments and deposits, the way every comparable marketplace does.
Chose
trov processes no money at all. The two people settle directly, and the app says so plainly.
Why
Two reasons, and they point the same way. A payment rail means a license, chargeback exposure, and a support desk I could not staff, and a half-built escrow implies a protection it cannot deliver. The better reason is the renter's: for an $18 drill from someone four streets away, a card form and a service fee are friction on a transaction people already complete in cash. What it costs is real, and worth saying. trov gives up fee revenue, gives up the leverage that holding money creates, and cannot arbitrate a payment dispute. That last one is why the photo record exists.
Considered
An insurance product or damage guarantee as the trust layer.
Chose
A shared photo record both sides capture at pickup and return.
Why
Insurance needs an underwriter and a claims process. A timestamped record costs nothing and settles the argument that actually happens, which is what condition it was in. Naming it and framing it as evidence rather than protection keeps the promise the same size as the thing behind it.
Considered
Launching with electronics, the highest-value category on the platform.
Chose
Cutting the category entirely before beta and folding cameras back into tools.
Why
High-value electronics are the highest-theft-risk listings, and at the time nothing verified who a renter actually was. Leading with them would have set the wrong expectation for the first listings and the first disputes. The category comes back once identity verification is required, which is the next thing being built.
Considered
Enforcing the free-listing cap at launch so the paid tiers earn from day one.
Chose
Building the tiers and shipping them switched off behind a single flag.
Why
A young marketplace dies of thin supply, not of unmonetized hosts. The pricing exists in code for the day it matters, and the hosts who show up early simply keep more than the cap. Building it and not turning it on was cheaper than retrofitting it later.
Considered
Launching on the public App Store for discoverability.
Chose
TestFlight first, seeded in a single neighborhood.
Why
A public listing is a one-shot reputation asset. The first thing a stranger does with an empty marketplace is leave a one-star review saying there is nothing near them, and that average follows every future install. TestFlight carries up to 10,000 testers with no public rating, and for a market recruited door to door, supply is the constraint, not discovery.
Where it stands
Built and in private beta
trov is a complete, working product rather than a prototype, and it is deliberately not public yet. There are no adoption numbers to report, so what follows is what exists.
A full two-sided marketplace
Renting and hosting are one app with two modes. Search, AI discovery, saved searches, messaging, the request-to-return lifecycle, reviews on both sides, and a host calendar all ship.
A real backend, not a mock
Postgres on Supabase with row-level security, scheduled jobs for reminders and nudges, and push notifications. The app also runs fully on in-memory fixtures, so it stays demonstrable with no backend at all.
Designed for App Review
In-app account deletion, reporting, and blocking were built to Apple's guidelines ahead of submission rather than in response to a rejection.
Revised on real hardware
Forty-eight recorded rounds of revision, each with its reasoning, plus the changes that came back from the first TestFlight build on other people’s phones.
Looking ahead
What I would want to learn next
Seed one neighborhood properly rather than opening signups. Whether the first search returns anything is the only metric that matters at this stage.
Watch whether the photo record actually gets used when something goes wrong. The entire trust model rests on an assumption I have not yet tested with strangers.
Make identity verification required before anyone can rent, then bring back the category I cut once every renter is checked.
Flip the listing cap only when the paid tiers genuinely exist, and let the early hosts keep what they were promised.
trov taught me that a marketplace is mostly an argument about trust, and the screens are the fastest part of making it. What took the time was deciding what the product would promise, and then having the discipline to say plainly what it would not, in the exact places where a more confident claim would have been easier to write.
Explore more work
People Skills
Led end-to-end design for AI-inferred skills across M365, Copilot, and Viva: trust and transparency patterns, admin controls, and the design system six product teams shipped against.
Virtual Appointments
Redesigned scheduling in Microsoft Teams and co-invented Lobby Chat, the U.S.-patented pre-meeting communication feature, cutting no-shows by up to 15% in healthcare and customer service scenarios.
Albertsons Pilot App
Designed the pilot that connected pharmacy guidance with grocery choices. 84% of pilot users reported greater awareness of healthier options, and its findings fed the app Albertsons later shipped.
Saver Fare Experience
Mixed-methods research with 60+ participants that shaped the Saver Fare launch, from renaming 'Choice' to 'Main' to the disclosure patterns that made fare restrictions clear before purchase.