Building a marketplace is one of the most complex challenges in digital product development. It’s not just about connecting buyers with sellers: you need to solve the chicken-and-egg problem, design an architecture supporting two market sides with different needs, implement trust and payment systems, and find a monetization model that generates value for all parties.
At Soamee we have had the opportunity to build four marketplaces in production, each in a different sector: ElDomi (student housing), TrasterOne (storage rental), Brytspace (B2B events) and Invisible Homes (PropTech with AI in London). In this article we share the most important lessons extracted from these projects.
The 4 marketplaces: quick context
Before diving into lessons, a brief context for each project:
ElDomi is a housing platform for university students. It connects students looking for rooms with property owners offering accommodation near universities. Main challenge: building trust between strangers who will share space, and managing the extreme seasonality of the student market.
TrasterOne is the storage space rental marketplace. It connects people needing storage with owners who have available storage units or garages. Challenge: precise geolocation search, recurring payments and access management.
Brytspace is a B2B marketplace for the events sector. It connects event organizers with service providers (catering, AV, decoration, venues). Challenge: quote request flows, business-to-business negotiation and coordination of multiple providers for a single event.
Invisible Homes is a PropTech marketplace in London for off-market properties. It connects qualified buyers with sellers who want to sell their property discreetly, without listing on public portals. Challenge: AI-powered matching between buyers and properties, buyer verification and over 80,000 registered users.
Lesson 1: The chicken-and-egg problem is solved by focusing on one side
The most common mistake when launching a marketplace is trying to attract both sides simultaneously. You need sellers to attract buyers, but sellers only come if there are buyers. This paradox has killed more marketplaces than any technical problem.
How we solved it
In ElDomi, we focused first on the supply side. We directly contacted flat owners near universities and offered them free listings. The value for them was clear: visibility to students at no cost. Once we had an attractive inventory of rooms, attracting students was relatively easy with social media campaigns targeted at university students.
In TrasterOne, the approach was similar but with a “single-player mode” strategy: even without tenants, owners could use the platform to manage their storage units (photos, prices, availability). This gave them immediate value without needing the other marketplace side to be active.
In Invisible Homes, the approach was different. They started with the demand side: registering qualified buyers with their search preferences. Once they had a significant database of verified buyers, they approached sellers with a concrete value proposition: “we have X buyers looking for exactly a property like yours in your area.”
The lesson: don’t try to solve both sides at once. Identify which of the two sides is harder to capture and concentrate your resources there first. The other side will come when there’s critical mass on the first.
Lesson 2: Trust is the most important feature
A marketplace is fundamentally a trust business. You’re asking two parties who don’t know each other to conduct a transaction through your platform. If you don’t generate trust, there’s no transaction.
Trust mechanisms we implemented
Identity verification: in ElDomi we implemented identity verification for both owners and students. Owners upload property photos that are manually verified. Students verify their university enrollment. This eliminated fake profiles and increased conversion rate by 35%.
Review systems: in TrasterOne we implemented a bidirectional review system (tenants rate storage units and owners rate tenants). We actively generated the first reviews by contacting early users for feedback. Once there was a minimum volume of reviews, the system was self-sustaining.
Escrow payments: in all marketplaces we implemented payments where money is held until both parties confirm the transaction. This eliminates risk for the buyer (if they don’t receive what they expected, they get their money back) and gives security to the seller (the buyer has already paid).
Platform guarantees: in Invisible Homes, the platform acts as intermediary verifying both buyers (financial capacity, genuine purchase motivation) and properties (ownership, legal status). This verification layer is the differentiating value versus traditional property portals.
The lesson: every design decision should be evaluated with the question “does this generate more or less trust?” Trust isn’t built with a single feature but with multiple small signals that accumulate.
Lesson 3: A marketplace MVP is more complex than a SaaS MVP
When building a SaaS, the MVP can be one core feature solving a problem for one type of user. In a marketplace, the minimum viable product is significantly more complex because you need to solve at least these pieces for the first transaction to occur:
- Listing: sellers can publish their offer
- Search: buyers can find what they’re looking for
- Communication: both parties can talk to each other
- Transaction: a payment can be completed securely
- Trust: some basic mechanism generating security
Our MVP approach
In all 4 projects we followed a similar strategy: build the minimum flow for a transaction to complete end-to-end, then iterate based on real data.
For Brytspace (the most recent), the MVP included:
- Provider catalog with category and location filters
- Provider profile with portfolio and services
- Quote request system (simple form)
- Internal messaging for negotiation
- Platform commission payment upon booking confirmation
We left out of the MVP: reviews, availability calendar, quote comparator, automatic invoicing and mobile app. All that came later, when we validated that users were completing transactions.
The lesson: resist the temptation to build all features before launching. The minimum marketplace enabling a complete transaction is your MVP. Everything else is hypotheses you must validate with real users.
Lesson 4: Search is the heart of the experience
In all four marketplaces, search quality directly determined conversion rate. If the buyer doesn’t quickly find what they’re looking for, they leave. And “quickly” means within the first 10 seconds.
Search implementations
TrasterOne was where geolocation search was most critical. We implemented map-based search with clustering, filters by size, price and features, and proximity-based sorting. We used PostGIS for geospatial queries and an interactive map with Mapbox where users can draw a search area. Conversion rate improved by 40% when we added map search versus the original paginated list.
Invisible Homes needed something more sophisticated: AI-powered matching. Instead of the buyer actively searching, the system analyzes their preferences (explicit and implicit based on behavior) and sends them matching properties. It’s a “Spotify for properties” model where the personalized feed has higher conversion than active search.
ElDomi combined search by university (campus proximity), filters by price and accommodation type (single room, shared, full apartment), and date availability (crucial given the student market operates by semesters and academic years).
Brytspace implemented faceted search with filters by service category, location, estimated budget and availability. For B2B events, search also includes filters by capacity, available equipment and service languages.
The lesson: invest disproportionately in the search experience. It’s the feature that most impacts conversion. Mediocre search kills a marketplace no matter how good everything else is.
Lesson 5: The monetization model must align with the moment of value
The most common monetization mistake in marketplaces is charging too early (before the user perceives value) or at the wrong moment (when it creates friction).
Models we implemented
TrasterOne charges a transaction commission added to the monthly rental price. The owner receives their asking price and the tenant pays a small additional percentage as a platform fee. The commission is charged monthly (recurring service), generating predictable revenue.
Brytspace charges suppliers a commission when a booking is confirmed. It doesn’t charge event organizers (the demand side that’s harder to attract). The commission is justified because the platform generates qualified leads the provider wouldn’t have otherwise.
Invisible Homes has a premium model: basic buyers see limited properties, and premium buyers (with subscription) get access to the full inventory and priority matching. Sellers pay a listing fee that includes verification and access to the qualified buyer database.
ElDomi charges the owner a commission equivalent to a percentage of the first month’s rent when a student confirms the booking. No charge if there’s no transaction (success-based model reducing the entry barrier for owners).
The lesson: charge at the moment value has already been delivered, not before. And charge the marketplace side that receives the most value from the platform. Experiment with the model until you find the point where users accept the price without significantly reducing transactions.
Lesson 6: Technical architecture must support two simultaneous evolutions
A marketplace evolves simultaneously in two dimensions: buyer features and seller features. Both sides have different roadmaps and different priorities. The architecture must allow evolving each side independently.
Key architectural decisions
Domain separation: in all 4 projects we clearly separated buyer, seller and operator (platform) domains. Each has its own set of endpoints, permissions and business logic. This allows a team to work on seller features without affecting the buyer experience.
Event-driven architecture: we implemented event-based architecture for critical actions (new listing, booking request, payment completed, review received). This allows adding reactions to these events without modifying the main flow (sending notifications, updating analytics, triggering automations).
API-first: all platforms were built with an API-first approach. The frontend (web and mobile) consumes the same APIs. This facilitates frontend evolution without touching the backend and vice versa.
Multi-tenancy for the seller side: in Brytspace and TrasterOne, each seller has their isolated “space” with their catalog, metrics and configuration. Implemented with row-level security in PostgreSQL, guaranteeing data isolation without multiple database complexity.
The lesson: design architecture thinking that both marketplace sides will evolve at different paces. Separation of concerns at code and data level will save you costly refactors later.
Lesson 7: Marketplace metrics are different
The metrics that matter in a marketplace are different from those of a SaaS or conventional e-commerce. If you measure the wrong things, you make wrong decisions.
Key metrics we monitor
- Liquidity: percentage of listings generating at least one transaction in a period. Low liquidity means a matching problem (lots of unsold supply) or demand problem (few active buyers).
- Time to first transaction: how long a new user (buyer or seller) takes to complete their first transaction. The shorter, the better.
- Repeat rate: percentage of users making more than one transaction. High repeat rate indicates the marketplace generates real value.
- GMV (Gross Merchandise Volume): total volume of processed transactions. The main growth metric.
- Take rate: percentage of GMV retained by the platform as revenue. Must balance profitability with user value.
- Supply-demand ratio: ratio between available supply and active demand. Too much supply, sellers get frustrated. Too much demand, buyers can’t find what they want.
The lesson: define your key metrics before launching and build the necessary instrumentation to measure them from day one. Product decisions in a marketplace should be data-driven, not intuition-driven.
Lesson 8: User support is part of the product
In a marketplace’s early phases, user support is a product function, not just an operational function. Every support interaction gives you information about what works and what doesn’t, and every satisfied user becomes an evangelist attracting others.
What we learned
In ElDomi, the first months we personally answered every query. This allowed us to detect that students were afraid to book a room without seeing it in person. The solution was implementing virtual visit video calls integrated into the platform, something we hadn’t contemplated in the initial design.
In TrasterOne, we discovered through support that owners had difficulty uploading quality photos of their storage units. The solution was creating an in-app photography guide with examples of good and bad photos, and an optional professional photography service for owners wanting to stand out.
The lesson: in early phases, talk directly to every user. Support isn’t a cost, it’s your main source of insights for product improvement.
Conclusion: universal principles
After building 4 marketplaces in different sectors, the repeating principles are:
- Focus your effort on one market side first (usually the supply side)
- Trust is built with multiple small signals, not a magic feature
- The MVP must enable a complete transaction, but nothing more
- Search determines conversion more than any other feature
- Charge when value has already been delivered, not before
- Design for two simultaneous evolutions with separated domains
- Measure the right metrics from day one
- Support is product in early phases
If you’re thinking about building a marketplace and want to learn from these 4 projects’ experience, schedule a free consultation where we can analyze your specific case and define the most efficient path from idea to first transaction.