Zaar's browse experience — category filters, search, and a card grid showing real student listings.
01 — The problem
College students needed a marketplace built for them.
My co-founder and I came up with the idea for Zaar while seniors at Brown. Moving into our apartments, we were frustrated by the process of trying to buy and sell items from other students on campus. People our age used Facebook groups or Instagram accounts to list things they were selling — which made it nearly impossible to search for what you wanted, and required building elaborate Google Slides presentations just to list something for sale.
We weren't trying to build the next eBay. We were trying to build the right tool for a specific community with a specific set of recurring needs: buying furniture at move-in, selling it at move-out, finding textbooks, offloading stuff before summer.
02 — Research
Four insights that shaped every design decision.
Before designing anything, I interviewed students to understand how they currently approached buying and selling on campus. The findings were clear and consistent.
Students trust other students, not strangersStudents — especially women — felt deeply uncomfortable transacting with strangers on Craigslist or Facebook Marketplace. Knowing the buyer or seller went to their school changed everything. This became the foundation of Zaar's trust model: university email verification on signup.
Ease and proximity matter more than priceStudents didn't mind walking to pick up something they'd bought, as long as it was from another student nearby. The friction of shipping — both cost and logistics — made platforms like Depop and Poshmark less appealing than a local exchange.
Facebook groups are broken for this use caseNo search. No filters. Endless scrolling through posts just to find a couch, only to message the seller and find out it was already sold. Students were actively frustrated with the tools they were using.
Secondhand is the preference, not the compromiseCollege students move every year. Spending money on furniture or goods they'll leave behind in twelve months felt wasteful. Secondhand wasn't a budget constraint — it was the rational choice.
03 — Design
The smallest version that could actually work.
I was responsible for every design decision — brand, information architecture, listing flows, browse and discovery, messaging, and the transaction experience. My co-founder handled engineering. We had no funding, no team, and a self-imposed deadline of six weeks.
We launched with listings, search and filtering by category, messaging, and a way to arrange a local exchange. No algorithmic feed. No shipping integration. No payment processing. Just the core loop: list, find, message, meet.
The trust layer was the most important design problem we solved. University email verification on signup — one decision — changed how both buyers and sellers behaved on the platform. It unlocked the in-person exchange model that shipping-based platforms couldn't support.
Product demo — browse, search, and listing flow on Zaar.
04 — Reflection
The 90/10 mindset — and why it still applies.
Zaar didn't become the company we hoped it would. We hit the classic cold-start problem — supply and demand had to grow together, and we didn't have the resources to subsidize either side long enough. But the product worked. Students used it, transactions happened, and the YC interview validated that the problem was real.
The thing I carry from this project into every project since — including complex enterprise work — is what I think of as the 90/10 mindset: how do you get 90% of the solution with 10% of the effort? At Zaar, that meant shipping search and categories before any personalization. It meant local exchange before payment processing. It meant university email before any sophisticated trust system.
In enterprise software, the same principle applies. On the task management project at Storable, we scoped to launch and retrieval — two task types — because that delivered 90% of the operational value without the complexity of a fully configurable system. The architecture was ready for more. The MVP wasn't trying to do more than it needed to.
Building Zaar is where I first understood that restraint is a design skill. Knowing what to leave out is harder than knowing what to put in.