Construir un marketplace es uno de los retos más complejos del desarrollo de producto digital. No se trata solo de conectar compradores con vendedores: hay que resolver el problema del huevo y la gallina, diseñar una arquitectura que soporte dos lados del mercado con necesidades diferentes, implementar sistemas de confianza y pagos, y encontrar un modelo de monetización que genere valor para todas las partes.
En Soamee hemos tenido la oportunidad de construir cuatro marketplaces en producción, cada uno en un sector diferente: ElDomi (alojamiento para estudiantes), TrasterOne (alquiler de trasteros), Brytspace (eventos B2B) e Invisible Homes (PropTech con IA en Londres). En este artículo compartimos las lecciones más importantes que hemos extraído de estos proyectos.
Los 4 marketplaces: contexto rápido
Antes de entrar en las lecciones, un contexto breve de cada proyecto:
ElDomi es una plataforma de alojamiento para estudiantes universitarios. Conecta estudiantes que buscan habitación con propietarios que ofrecen alojamiento cerca de universidades. El reto principal: generar confianza entre extraños que van a compartir espacio, y gestionar la estacionalidad extrema del mercado estudiantil.
TrasterOne es el marketplace de alquiler de trasteros. Conecta personas que necesitan espacio de almacenamiento con propietarios que tienen trasteros o garajes disponibles. El reto: búsqueda geolocalizada precisa, pagos recurrentes y gestión de accesos.
Brytspace es un marketplace B2B para el sector de eventos. Conecta organizadores de eventos con proveedores de servicios (catering, AV, decoración, espacios). El reto: flujos de solicitud de presupuesto, negociación entre empresas y coordinación de múltiples proveedores para un mismo evento.
Invisible Homes es un marketplace PropTech en Londres para propiedades off-market. Conecta compradores cualificados con vendedores que quieren vender su propiedad de forma discreta, sin publicarla en portales públicos. El reto: matching por IA entre compradores y propiedades, verificación de compradores y más de 80.000 usuarios registrados.
Lección 1: El problema del huevo y la gallina se resuelve concentrándose en un lado
El error más común al lanzar un marketplace es intentar atraer ambos lados simultáneamente. Necesitas vendedores para atraer compradores, pero los vendedores solo vienen si hay compradores. Esta paradoja ha matado más marketplaces que cualquier problema técnico.
Cómo lo resolvimos
En ElDomi, nos concentramos primero en el lado de la oferta. Contactamos directamente con propietarios de pisos cerca de universidades y les ofrecimos publicar sus habitaciones gratis. El valor para ellos era claro: visibilidad ante estudiantes sin coste. Una vez que teníamos un inventario atractivo de habitaciones, atraer estudiantes fue relativamente fácil con campañas en redes sociales dirigidas a universitarios.
En TrasterOne, el enfoque fue similar pero con una estrategia de “single-player mode”: incluso sin inquilinos, los propietarios podían usar la plataforma para gestionar sus trasteros (fotos, precios, disponibilidad). Esto les daba valor inmediato sin necesidad de que el otro lado del marketplace estuviera activo.
En Invisible Homes, el approach fue diferente. Empezaron por el lado de la demanda: registrar compradores cualificados con sus preferencias de búsqueda. Una vez que tenían una base de datos significativa de compradores verificados, se acercaban a vendedores con una propuesta de valor concreta: “tenemos X compradores que buscan exactamente una propiedad como la tuya en tu zona.”
La lección: no intentes resolver ambos lados a la vez. Identifica cuál de los dos lados es más difícil de captar y concentra tus recursos ahí primero. El otro lado vendrá cuando haya masa crítica en el primero.
Lección 2: La confianza es la funcionalidad más importante
Un marketplace es fundamentalmente un negocio de confianza. Estás pidiendo a dos partes que no se conocen que realicen una transacción a través de tu plataforma. Si no generas confianza, no hay transacción.
Mecanismos de confianza que implementamos
Verificación de identidad: en ElDomi implementamos verificación de identidad tanto para propietarios como para estudiantes. Los propietarios suben fotos del inmueble que son verificadas manualmente. Los estudiantes verifican su matricula universitaria. Esto eliminó los perfiles falsos y aumentó la tasa de conversión un 35%.
Sistemas de reseñas: en TrasterOne implementamos un sistema de reseñas bidireccional (inquilinos valoran trasteros y propietarios valoran inquilinos). Las primeras reseñas las generamos activamente contactando a los primeros usuarios para pedirles feedback. Una vez que había un volumen mínimo de reseñas, el sistema se alimentaba solo.
Pagos seguros en escrow: en todos los marketplaces implementamos pagos donde el dinero se retiene hasta que ambas partes confirman la transacción. Esto elimina el riesgo para el comprador (si no recibe lo que esperaba, recupera su dinero) y da seguridad al vendedor (el comprador ya ha pagado).
Garantías de la plataforma: en Invisible Homes, la plataforma actúa como intermediario que verifica tanto a compradores (capacidad financiera, motivación real de compra) como a propiedades (titularidad, estado legal). Esta capa de verificación es el valor diferencial frente a portales inmobiliarios tradicionales.
La lección: cada decisión de diseño debe evaluarse con la pregunta “esto genera más o menos confianza?”. La confianza no se construye con una sola funcionalidad sino con múltiples señales pequeñas que se acumulan.
Lección 3: El MVP de un marketplace es más complejo que el de un SaaS
Cuando construyes un SaaS, el MVP puede ser una funcionalidad core que resuelve un problema para un tipo de usuario. En un marketplace, el MVP mínimo viable es significativamente más complejo porque necesitas resolver al menos estas piezas para que la primera transacción ocurra:
- Listado: los vendedores pueden publicar su oferta
- Búsqueda: los compradores pueden encontrar lo que buscan
- Comunicación: ambas partes pueden hablar entre sí
- Transacción: se puede completar un pago de forma segura
- Confianza: algún mecanismo básico que genere seguridad
Nuestro approach de MVP
En los 4 proyectos seguimos una estrategia similar: construir el flujo mínimo para que una transacción complete de principio a fin, y luego iterar basándonos en datos reales.
Para Brytspace (el más reciente), el MVP incluía:
- Catálogo de proveedores con filtro por categoría y ubicación
- Perfil de proveedor con portfolio y servicios
- Sistema de solicitud de presupuesto (formulario simple)
- Mensajería interna para negociación
- Pago de la comisión de la plataforma al confirmar la reserva
Dejamos fuera del MVP: reviews, calendario de disponibilidad, comparador de presupuestos, facturación automática y app móvil. Todo eso vino después, cuando validamos que los usuarios completaban transacciones.
La lección: resiste la tentación de construir todas las funcionalidades antes de lanzar. El marketplace mínimo que permite una transacción completa es tu MVP. Todo lo demás son hipótesis que debes validar con usuarios reales.
Lección 4: La búsqueda es el corazón de la experiencia
En los cuatro marketplaces, la calidad de la búsqueda determinó directamente la tasa de conversión. Si el comprador no encuentra rápidamente lo que busca, se va. Y “rápidamente” significa en los primeros 10 segundos.
Implementaciones de búsqueda
TrasterOne fue donde la búsqueda geolocalizada fue más crítica. Implementamos búsqueda por mapa con clustering, filtros por tamaño, precio y características, y ordenación por proximidad. Utilizamos PostGIS para queries geoespaciales y un mapa interactivo con Mapbox donde los usuarios pueden dibujar un área de búsqueda. La tasa de conversión mejoró un 40% cuando añadimos la búsqueda por mapa frente a la lista paginada original.
Invisible Homes necesitaba algo más sofisticado: matching por IA. En lugar de que el comprador busque activamente, el sistema analiza sus preferencias (explícitas e implícitas basadas en comportamiento) y le envía propiedades que encajan con su perfil. Es un modelo tipo “Spotify de propiedades” donde el feed personalizado tiene mayor conversión que la búsqueda activa.
ElDomi combinaba búsqueda por universidad (proximidad al campus), filtros por precio y tipo de alojamiento (habitación individual, compartida, piso completo), y disponibilidad por fechas (crucial dado que el mercado estudiantil opera por semestres y cursos académicos).
Brytspace implementó búsqueda facetada con filtros por categoría de servicio, ubicación, presupuesto estimado y disponibilidad. Para eventos B2B, la búsqueda también incluye filtros por capacidad, equipamiento disponible y idiomas de servicio.
La lección: invierte desproporcionadamente en la experiencia de búsqueda. Es la funcionalidad que más impacta en la conversión. Una búsqueda mediocre mata un marketplace por bueno que sea todo lo demás.
Lección 5: El modelo de monetización debe alinearse con el momento de valor
El error más común en monetización de marketplaces es cobrar demasiado pronto (antes de que el usuario perciba valor) o en el momento equivocado (cuando genera fricción).
Modelos que implementamos
TrasterOne cobra una comisión por transacción que se añade al precio del alquiler mensual. El propietario recibe lo que pide y el inquilino paga un pequeño porcentaje adicional como fee de plataforma. La comisión se cobra cada mes (es un servicio recurrente), lo que genera revenue predecible.
Brytspace cobra una comisión al proveedor cuando se confirma una reserva. No cobra al organizador del evento (el lado de la demanda que es más difícil de captar). La comisión se justifica porque la plataforma genera leads cualificados que el proveedor no tendría de otra forma.
Invisible Homes tiene un modelo premium: los compradores básicos ven propiedades limitadas, y los compradores premium (con suscripción) tienen acceso a todo el inventario y matching prioritario. Los vendedores pagan un fee de listado que incluye la verificación y el acceso a la base de compradores cualificados.
ElDomi cobra al propietario una comisión equivalente a un porcentaje del primer mes de alquiler cuando un estudiante confirma la reserva. No cobra nada si no hay transacción (modelo success-based que reduce la barrera de entrada para propietarios).
La lección: cobra en el momento en que el valor ya se ha entregado, no antes. Y cobra al lado del marketplace que más valor recibe de la plataforma. Experimenta con el modelo hasta encontrar el punto donde los usuarios aceptan el precio sin que reduzca significativamente las transacciones.
Lección 6: La arquitectura técnica debe soportar dos evoluciones simultáneas
Un marketplace evoluciona simultáneamente en dos dimensiones: funcionalidades para compradores y funcionalidades para vendedores. Ambos lados tienen roadmaps diferentes y prioridades diferentes. La arquitectura debe permitir evolucionar cada lado de forma independiente.
Decisiones arquitectónicas clave
Separación de dominios: en los 4 proyectos separamos claramente los dominios de comprador, vendedor y operador (la plataforma). Cada uno tiene su propio conjunto de endpoints, permisos y lógica de negocio. Esto permite que un equipo trabaje en funcionalidades de vendedor sin afectar la experiencia del comprador.
Event-driven architecture: implementamos una arquitectura basada en eventos para las acciones críticas (nueva publicación, solicitud de reserva, pago completado, reseña recibida). Esto permite añadir reacciones a estos eventos sin modificar el flujo principal (por ejemplo, enviar notificaciones, actualizar analytics, triggear automatizaciones).
API-first: todas las plataformas se construyeron con un approach API-first. El frontend (web y móvil) consume las mismas APIs. Esto facilita la evolución del frontend sin tocar el backend y viceversa.
Multi-tenancy para el lado vendedor: en Brytspace y TrasterOne, cada vendedor tiene su “espacio” aislado con su catálogo, sus métricas y su configuración. Esto se implementó con row-level security en PostgreSQL, lo que garantiza aislamiento de datos sin la complejidad de múltiples bases de datos.
La lección: diseña la arquitectura pensando en que los dos lados del marketplace evolucionarán a ritmos diferentes. La separación de concerns a nivel de código y datos te ahorrará refactors costosos más adelante.
Lección 7: Las métricas de un marketplace son diferentes
Las métricas que importan en un marketplace son distintas a las de un SaaS o un e-commerce convencional. Si mides las cosas equivocadas, tomas decisiones equivocadas.
Métricas clave que monitorizamos
- Liquidity: porcentaje de listados que generan al menos una transacción en un período. Si la liquidity es baja, tienes un problema de matching (mucha oferta que no se vende) o de demanda (pocos compradores activos).
- Time to first transaction: cuánto tarda un nuevo usuario (comprador o vendedor) en completar su primera transacción. Cuanto menor, mejor.
- Repeat rate: porcentaje de usuarios que realizan más de una transacción. Un repeat rate alto indica que el marketplace genera valor real.
- GMV (Gross Merchandise Volume): volumen total de transacciones procesadas. Es la métrica de crecimiento principal.
- Take rate: porcentaje del GMV que retiene la plataforma como revenue. Debe equilibrar rentabilidad con valor para los usuarios.
- Supply-demand ratio: ratio entre oferta disponible y demanda activa. Si hay demasiada oferta, los vendedores se frustran. Si hay demasiada demanda, los compradores no encuentran lo que buscan.
La lección: define tus métricas clave antes de lanzar y construye la instrumentación necesaria para medirlas desde el día uno. Las decisiones de producto en un marketplace deben basarse en datos, no en intuiciones.
Lección 8: El soporte al usuario es parte del producto
En las fases iniciales de un marketplace, el soporte al usuario es una función de producto, no solo una función operativa. Cada interacción de soporte te da información sobre lo que funciona y lo que no, y cada usuario satisfecho se convierte en un evangelista que atrae a otros.
Lo que aprendimos
En ElDomi, los primeros meses respondimos personalmente cada consulta. Esto nos permitió detectar que los estudiantes tenían miedo de reservar una habitación sin verla en persona. La solución fue implementar videollamadas de visita virtual integradas en la plataforma, algo que no habíamos contemplado en el diseño inicial.
En TrasterOne, descubrimos a través del soporte que los propietarios tenían dificultades para subir fotos de calidad de sus trasteros. La solución fue crear una guía de fotografía in-app con ejemplos de buenas y malas fotos, y un servicio opcional de fotografía profesional para propietarios que querían destacar.
La lección: en las primeras fases, habla directamente con cada usuario. El soporte no es un coste, es tu principal fuente de insights para mejorar el producto.
Conclusión: los principios universales
Después de construir 4 marketplaces en sectores diferentes, los principios que se repiten son:
- Concentra tu esfuerzo en un lado del mercado primero (normalmente el lado de la oferta)
- La confianza se construye con múltiples señales pequeñas, no con una funcionalidad mágica
- El MVP debe permitir una transacción completa, pero nada más
- La búsqueda determina la conversión más que cualquier otra funcionalidad
- Cobra cuando el valor ya se ha entregado, no antes
- Diseña para dos evoluciones simultáneas con dominios separados
- Mide las métricas correctas desde el día uno
- El soporte es producto en las fases iniciales
Si estás pensando en construir un marketplace y quieres aprender de la experiencia de estos 4 proyectos, agenda una consultoría gratuita donde podemos analizar tu caso específico y definir el camino más eficiente desde la idea hasta la primera transacción.