Desarrollo de MVP: La guía completa para fundadores (qué construir y qué omitir)
Una guía práctica para construir un Producto Mínimo Viable — cómo definir el alcance del MVP, qué funcionalidades eliminar, cuánto tiempo lleva, cuánto cuesta y los errores que convierten los MVPs en fracasos costosos.
La frase «simplemente construye un MVP» se ha repetido tantas veces en los círculos de startups que casi ha perdido su significado. La escuchamos de inversores, incubadoras, artículos de blog y gestores de programas de aceleración. El consejo es correcto en principio — pero la forma en que la mayoría de los equipos lo aplica los lleva a un lugar costoso y desmoralizante.
En Cyberbeak, hemos atravesado este proceso con fundadores de decenas de sectores — fintech, healthtech, SaaS B2B, marketplaces, herramientas internas. Los equipos que construyen bien sus MVPs no son los que avanzan más rápido ni los que gastan menos dinero. Son los que entienden qué significa realmente la palabra «mínimo», qué exige realmente la palabra «viable» y dónde vive la tensión entre esas dos ideas.
Esta guía es la versión de la conversación sobre MVP que mantenemos en cada llamada de descubrimiento, escrita en su totalidad. Cubriremos qué construir, qué eliminar sin dudar, cómo son un presupuesto y un cronograma realistas, los errores que vemos con más frecuencia y cómo gestionamos nuestros propios proyectos de MVP. Si estás a punto de invertir dinero en un producto, aquí está la verdad — no un discurso de ventas que abogue por la complejidad, ni una carrera a la baja en precios.
Qué es y qué no es un MVP
El término Producto Mínimo Viable proviene de Eric Ries y la metodología Lean Startup, y su significado original merece ser revisado porque se aplica incorrectamente con frecuencia.
Ries definió el MVP como «esa versión de un nuevo producto que permite a un equipo recopilar la máxima cantidad de aprendizaje validado sobre los clientes con el menor esfuerzo». La palabra clave en esa oración es validado. Un MVP no es un producto barato — es una herramienta de aprendizaje. Existe para responder una pregunta específica: ¿este enfoque resuelve un problema real para personas reales de una manera que podría convertirse en un negocio sostenible?
Esta distinción importa enormemente en la práctica, porque las dos interpretaciones erróneas más comunes de «MVP» llevan a los equipos en direcciones opuestas — ambas equivocadas.
Interpretación errónea uno: MVP significa construirlo rápido y barato. Los equipos que operan bajo esta creencia lanzan software con errores y confuso, y lo llaman validado. Los usuarios se van, la confianza se evapora, y los fundadores concluyen «el mercado no está listo» cuando el verdadero problema es que el producto no era viable. Mínimo no significa defectuoso.
Interpretación errónea dos: MVP significa construir todo de una vez. Los equipos que operan bajo esta creencia pasan seis meses construyendo un panel de administración, cuatro métodos de pago, una aplicación móvil y una página completa de configuración antes de mostrárselo a alguien. Lo llaman «MVP» porque es solo su primera versión. Para cuando lanzan, han agotado su capital y sus suposiciones están integradas en código que no pueden cambiar fácilmente.
Seamos precisos. «Mínimo» significa el conjunto más pequeño de funcionalidades que aún entrega la propuesta de valor central. Si se elimina algo más, el producto no funciona lo suficientemente bien como para probar la hipótesis. «Viable» significa que funciona con la suficiente fiabilidad como para que alguien lo use genuinamente. No con un diseño hermoso. No con todas las funcionalidades. Pero estable, coherente y realmente útil para un usuario real.
Un buen MVP no es la mitad de un producto. Es un producto completo con un alcance deliberadamente reducido.
Cómo definir el alcance de tu MVP
La definición del alcance es donde la mayoría de los proyectos de MVP tienen éxito o fracasan antes de escribir una sola línea de código. El instinto es definir el alcance listando funcionalidades — «necesitamos inicio de sesión, un panel de control, un feed, notificaciones, exportación a CSV y una página de configuración». Esa lista no tiene ninguna lógica detrás. Es simplemente una lista de deseos.
Usamos dos marcos de trabajo complementarios para ayudar a los fundadores a definir correctamente el alcance.
Mapeo de historias de usuario
El mapeo de historias de usuario, desarrollado por Jeff Patton, te pide que pienses en tu producto como una secuencia de actividades que realiza un usuario, no como una lista de funcionalidades. Comienzas escribiendo el recorrido completo del usuario de extremo a extremo en un nivel alto — las cosas que hace para alcanzar su objetivo. Bajo cada actividad, escribes las tareas individuales necesarias. Luego trazas una línea horizontal: todo lo que está por encima de la línea es tu MVP. Todo lo que está por debajo es una versión posterior.
La potencia de esta técnica es que mantiene visible todo el recorrido del usuario mientras obliga a tomar decisiones difíciles. No puedes hacer trampa eliminando un flujo de trabajo completo — los usuarios aún necesitan completar su recorrido, solo con el mínimo número de pasos. Lo que cae por debajo de la línea no se abandona, se desprioriza. Eso es algo muy diferente desde el punto de vista psicológico y operativo.
Trabajos por realizar
El marco Jobs to Be Done, asociado con Clayton Christensen, pregunta: ¿para qué trabajo está contratando el usuario este producto? No qué funcionalidades quiere — qué resultado está tratando de lograr en su vida o trabajo.
Cuando conoces el trabajo, puedes evaluar cada funcionalidad propuesta en función de él: ¿esta funcionalidad ayuda a los usuarios a completar ese trabajo más rápido, de forma más fiable o con menos fricción? Si la respuesta es no o «más o menos», probablemente no sea parte del MVP. Si la respuesta es sí y los usuarios no pueden completar el trabajo sin ella, pertenece al alcance.
Combina estos dos enfoques y obtienes algo valioso: un alcance definido en torno a los resultados del usuario en lugar de las suposiciones del fundador. Ese es el único alcance que vale la pena construir.
Qué incluir siempre en un MVP
Algunas cosas nunca son opcionales, independientemente del tipo de producto. Estos son los elementos que hacen que un producto sea viable en el sentido más genuino.
Flujos principales del usuario
Independientemente de lo que haga tu producto, el flujo de trabajo principal — aquello que entrega el valor central — debe estar completo y funcional. Si tu producto ayuda a los freelancers a enviar facturas, el flujo de creación, vista previa y envío de facturas no puede ser un esquema incompleto. Ese es el trabajo. Todo lo demás es opcional en relación con ese trabajo.
Autenticación y control de acceso
Los usuarios necesitan crear cuentas, iniciar sesión de forma segura y, en la mayoría de los contextos B2B, tener sus datos aislados de otros usuarios. La autenticación no es algo deseable sino imprescindible. Incluso una configuración simple de correo electrónico y contraseña con gestión segura de sesiones es el requisito mínimo. Si tu producto maneja cualquier cosa remotamente sensible — datos financieros, información de salud, registros empresariales — también necesitas flujos de restablecimiento de contraseña y separación básica de roles.
Persistencia de datos
Los datos de tus usuarios deben guardarse de forma fiable y ser recuperables entre sesiones. Esto parece obvio, pero «ya me ocuparé de la base de datos más adelante» es una frase que le ha costado a los equipos meses de trabajo adicional. Diseña tu modelo de datos antes de construir — es mucho más difícil cambiarlo después que casi cualquier otra cosa en el software.
Manejo de errores
Los usuarios encontrarán errores. Los servidores caen, las llamadas a la API fallan, los envíos de formularios llegan a estados inesperados. Si tu MVP responde a cada problema con una pantalla en blanco o una página genérica de error 500, perderás usuarios que podrían haber permanecido si el producto simplemente hubiera explicado qué pasó y qué hacer a continuación. El manejo de errores no es un acabado fino — es parte de la viabilidad.
Analíticas básicas
No puedes aprender de tu MVP si no puedes ver cómo se está utilizando. Como mínimo, instrumenta los registros de usuarios, el uso de las funcionalidades principales y los puntos de abandono. Herramientas como Mixpanel, PostHog o incluso una configuración bien configurada de Google Analytics cuestan casi nada integrarlas y te brindan datos que necesitarás en el momento en que lleguen los usuarios.
Qué eliminar de tu MVP
Esta es la sección que ahorra dinero. Si tu MVP propuesto incluye alguno de los siguientes elementos, casi con certeza recomendaremos eliminarlo durante el proceso de descubrimiento.
Paneles de administración
Los paneles internos para gestionar usuarios, ver datos, cambiar configuraciones y ejecutar informes parecen esenciales — porque en algún momento lo serán. Pero en las primeras 8 a 16 semanas de vida de tu producto, tienes un puñado de usuarios. Puedes gestionarlos directamente en tu base de datos, o mediante una hoja de cálculo básica, o con una herramienta sin código como Retool que lleva un día configurar. Construir una interfaz de administración pulida antes de tener un volumen significativo de usuarios es construir para un problema que todavía no tienes.
Búsqueda avanzada y filtrado
La búsqueda es costosa de construir bien. La búsqueda de texto completo con facetas, filtros, búsquedas guardadas y clasificación por relevancia es ingeniería genuinamente compleja. A menos que tu propuesta de valor central sea literalmente «encontrar la cosa correcta», las vistas de lista simples con controles básicos de ordenación servirán a tus primeros usuarios igual de bien — y te dirán exactamente qué filtros realmente quieren antes de que los construyas.
Múltiples métodos de pago
Si tu producto acepta pagos, un método de pago es suficiente. Stripe es el estándar del sector y gestiona tarjetas, Apple Pay y Google Pay en una sola integración. Añadir PayPal, débito directo, transferencia bancaria y facturación en una primera versión añade semanas de desarrollo y mantenimiento por un aumento muy pequeño en la conversión con los volúmenes iniciales de usuarios.
Aplicaciones móviles nativas
A menos que tu producto sea genuinamente mobile-first — un caso de uso que realmente requiera acceso a la cámara, notificaciones push, GPS o funcionalidad sin conexión — no construyas una aplicación nativa de iOS o Android en tu MVP. Una aplicación web responsiva funciona en los navegadores móviles. Se lanza más rápido, cuesta una fracción del desarrollo nativo, y te dice si los usuarios quieren una experiencia móvil antes de que inviertas en construirla.
Funcionalidades sociales y comunitarias
Los perfiles de usuario, las conexiones con amigos, los feeds de actividad, los comentarios, los me gusta y la mensajería son superficies de producto completas por sí mismas. Si no son la propuesta de valor central, son una distracción. Los productos que han intentado incorporar efectos de red en su MVP casi universalmente lo han lamentado. Resuelve primero el problema del usuario individual.
Soporte multilingüe y de múltiples monedas
La internacionalización es un compromiso de ingeniería costoso y que consume mucho tiempo, que afecta a cada cadena de texto en tu código y cada número en tu modelo de datos. Lanza en un idioma y una moneda. Cuando tengas evidencia de demanda en otro mercado, localiza en ese momento — no antes.
Coste y cronograma del MVP
Los costes dependen de la complejidad, la composición del equipo y si el proyecto incluye diseño, descubrimiento y QA. La tabla a continuación refleja rangos realistas para un socio de desarrollo de software en el mercado del Reino Unido con un equipo dedicado.
| Tipo de producto | Qué incluye habitualmente | Cronograma | Rango de presupuesto |
|---|---|---|---|
| Herramienta interna | Flujo de trabajo de usuario único, autenticación básica, vistas de datos, activadores manuales | 6–8 semanas | £20,000 – £50,000 |
| SaaS MVP | Autenticación multi-tenant, conjunto de funcionalidades básicas, pagos con Stripe, panel básico | 10–14 semanas | £60,000 – £120,000 |
| Marketplace MVP | Tipos de usuarios bidireccionales, listados, flujo de reserva o transacción, notificaciones | 12–18 semanas | £80,000 – £180,000 |
| Aplicación móvil MVP | React Native o Flutter multiplataforma, flujo principal, notificaciones push | 12–16 semanas | £70,000 – £150,000 |
Estos rangos asumen una fase de descubrimiento, diseño UX, desarrollo backend y frontend, QA y despliegue. No incluyen contratos de mantenimiento posteriores al lanzamiento, que típicamente oscilan entre £3,000 y £8,000 al mes según el alcance.
Las variables que elevan los costes son: integraciones de API de terceros con documentación deficiente, lógica de negocio compleja (por ejemplo, motores de precios, algoritmos de programación), requisitos de cumplimiento normativo (manejo de datos según el RGPD, consideraciones de la FCA para fintech) y funcionalidades en tiempo real (chat en vivo, edición colaborativa, paneles de datos en tiempo real).
Las variables que reducen los costes son: un alcance claro y estable antes de la construcción, la reutilización de sistemas de diseño existentes, proveedores de autenticación estándar (Auth0, Clerk) y equipos que hayan construido productos similares antes y puedan aprovechar patrones existentes.
Los mayores errores de MVP que vemos
Después de construir MVPs en muchos sectores, vemos los mismos modos de fallo repetirse con una consistencia notable.
Exceso de construcción por expansión del alcance
La expansión del alcance no suele llegar como un cambio dramático — llega como pequeñas adiciones que cada una parece razonable de forma aislada. «¿Podemos simplemente añadir una pantalla de preferencias de notificación?» «¿Y si los usuarios pudieran invitar a su equipo?» «Probablemente deberíamos tener un registro de cambios». Cada solicitud individual es defendible. Juntas, extienden un proyecto de 8 semanas a un proyecto de 20 semanas y agotan el presupuesto antes de que el producto haya estado frente a un usuario real.
La solución es un documento de alcance escrito, acordado antes de que comience el desarrollo, con un proceso formal de control de cambios. Cualquier adición se evalúa según su impacto en el cronograma y el presupuesto antes de aceptarla — no después.
Falta de pruebas
La presión económica para lanzar rápido lleva a los equipos a despriorizar el QA. «Arreglaremos los errores a medida que aparezcan». El problema es que los errores en la primera semana de un producto no solo crean tickets de soporte — crean una primera impresión. Un usuario que pierde datos, se encuentra con un flujo defectuoso o ve un error confuso en su primera sesión raramente vuelve. La confianza en el software se construye lentamente y se destruye de inmediato.
Tratamos las pruebas como un entregable de primera clase, no como un paso final opcional. Las pruebas automatizadas, los sprints de QA estructurados y las pruebas de aceptación de usuario antes del lanzamiento son parte de cada proyecto — no extras que se eliminan cuando el cronograma se ajusta.
Construir sin métricas de éxito definidas
El propósito de un MVP es aprender. Pero aprender requiere saber de antemano qué estás tratando de descubrir. «¿Les gustó a los usuarios?» no es una métrica de éxito. «¿El 30% de los registros completó su primera acción principal en 24 horas?» sí es una métrica de éxito. Define tus métricas antes de construir, no después del lanzamiento. De lo contrario, racionalizarás cualquier resultado que obtengas — y perderás la señal que el MVP intentaba enviarte.
Construir lo que quieres, no lo que los usuarios necesitan
Los fundadores, de forma muy natural, están cerca de su idea. Esa cercanía es una fortaleza — crea convicción e impulso. También es un riesgo, porque facilita construir el producto que deseas que exista en lugar del producto que tu usuario objetivo realmente necesita. La distinción solo se hace clara a través de la investigación de usuarios, y la mayoría de los fundadores la omiten porque están convencidos de que ya lo saben.
Los MVPs que hemos visto fracasar casi siempre tenían algo en común: fueron construidos sin una aportación significativa de las personas a las que se suponía que debían servir.
Validación previa al MVP
Antes de escribir una línea de código, hay una pregunta que vale la pena hacerse honestamente: ¿has validado que este problema es real y que los usuarios pagarían a alguien para resolverlo?
La validación previa al MVP no requiere software. Requiere hablar con usuarios potenciales y observar lo que hacen, no solo escuchar lo que dicen.
Las páginas de aterrizaje pueden validar la demanda antes de que exista un producto. Una propuesta de valor clara, un formulario de registro y una pequeña cantidad de tráfico pagado pueden decirte si las personas están suficientemente interesadas como para proporcionar su dirección de correo electrónico. Si no puedes obtener una tasa de conversión del 5% en una página de aterrizaje, ese es un dato que vale la pena entender antes de gastar £80,000 en un desarrollo.
Los prototipos interactivos — construidos en Figma o herramientas similares — te permiten poner una representación interactiva del producto frente a los usuarios y observar dónde se confunden, qué esperan que suceda y si el flujo principal tiene sentido. Esto cuesta días, no meses.
Los procesos manuales (a veces llamados pruebas «Mago de Oz») te permiten simular el producto completamente a mano. Un producto de planificación de viajes puede simularse con un investigador haciendo investigación manual y enviando resultados por correo electrónico. Una herramienta de extracción de datos puede simularse con una persona haciendo la extracción. Aprendes si el resultado es valioso antes de automatizar el proceso.
Rutinariamente aconsejamos a los fundadores que inviertan de 4 a 8 semanas en la validación previa al MVP antes de comprometerse con un presupuesto de desarrollo. Las conversaciones que tengas durante esa fase redefinirán tu alcance de maneras que ahorrarán tiempo y dinero significativos más adelante.
Del MVP a la V1.0
El lanzamiento no es la línea de llegada — es el pistoletazo de salida. En el momento en que los usuarios reales toquen tu producto, aprenderás cosas que ninguna cantidad de investigación, prototipado o pruebas internas podrían haberte dicho.
Recopilar y procesar comentarios
Instrumenta tu producto cuidadosamente antes del lanzamiento. Combina analíticas cuantitativas (adónde van los usuarios, en qué hacen clic, dónde se detienen) con retroalimentación cualitativa (encuestas en la aplicación, conversaciones directas, tickets de soporte). La señal más útil es casi siempre conductual — lo que los usuarios hacen importa más que lo que dicen que quieren.
Establece una cadencia para revisar estos datos. Revisiones semanales del producto en las semanas posteriores al lanzamiento, pasando a quincenales a medida que la señal se estabilice.
Cuándo iterar frente a cuándo reconstruir
La mayoría de los equipos debería iterar después de un MVP — refinar el flujo principal, corregir puntos de fricción, ampliar el alcance de forma incremental basándose en evidencia. La reconstrucción debe reservarse para situaciones en las que la arquitectura es genuinamente limitante (lo cual es raro después de un MVP bien construido) o donde la hipótesis ha cambiado tan fundamentalmente que el producto necesita una dirección completamente diferente.
Las reconstrucciones son costosas y desmoralizantes. El camino hacia la V1.0 es generalmente incremental: sprints de dos semanas, priorizados por la retroalimentación de usuarios, con criterios de aceptación claros para cada funcionalidad antes de que entre en desarrollo.
Saber cuándo estás listo para escalar
La V1.0 no es un hito arbitrario. Es el punto en el que has logrado el ajuste producto-mercado — evidencia de que un grupo repetible y escalable de usuarios valora genuinamente lo que has construido y se sentiría significativamente decepcionado si desapareciera. Hasta que esa evidencia esté en mano, escalar (ventas, marketing, contrataciones) es prematuro. Arregla el producto antes de amplificarlo.
Cómo gestionamos los proyectos de MVP en Cyberbeak
Nuestros proyectos de MVP generalmente se desarrollan en tres fases, abarcando de 8 a 16 semanas según el alcance.
Fase uno: Descubrimiento (semanas 1–2)
Pasamos las primeras dos semanas en un descubrimiento estructurado — sin escribir código. Revisamos tus objetivos de negocio, mapeamos tus usuarios objetivo, auditamos cualquier investigación o prototipo existente, definimos las métricas de éxito para el MVP y acordamos el alcance por escrito. El resultado es un documento de descubrimiento que se convierte en la estrella polar para todo lo que sigue. Cada decisión de funcionalidad hace referencia a él.
Esta fase previene la expansión del alcance, alinea nuestro equipo y el tuyo sobre exactamente qué se está construyendo, y típicamente saca a la luz suposiciones que se habrían convertido en problemas costosos a mitad del sprint.
Fase dos: Diseño y construcción (semanas 3–14)
El diseño y el desarrollo se ejecutan en paralelo en lugar de en secuencia. Nuestros diseñadores producen wireframes y prototipos interactivos temprano — generalmente al final de la tercera semana — para que el equipo técnico pueda comenzar la arquitectura del backend mientras los diseños se iteran y aprueban. Trabajamos en sprints de dos semanas, con software funcional demostrado al final de cada sprint.
Incluido en cada proyecto: diseño UX/UI, desarrollo frontend, desarrollo backend, configuración de infraestructura (alojamiento en la nube, pipeline CI/CD, entornos de staging y producción), integraciones de terceros según el alcance, pruebas automatizadas, sprints de QA antes del lanzamiento.
Fase tres: Lanzamiento y entrega (semanas 15–16)
Despliegue en producción, validación del rendimiento, pruebas de carga con los volúmenes de usuarios esperados, configuración de monitoreo y alertas, y una entrega completa de documentación y credenciales. Permanecemos durante un breve período de soporte posterior al lanzamiento para resolver cualquier problema que surja con el tráfico real.
Después del lanzamiento, la mayoría de los clientes pasan a un contrato mensual de mantenimiento para el desarrollo continuo — iterando según la retroalimentación de usuarios en sprints quincenales.
Preguntas frecuentes
¿Cómo sé si mi idea está lista para un MVP?
Tu idea está lista para un MVP cuando puedes articular claramente quién es tu usuario objetivo, qué problema específico tiene y por qué tu enfoque para resolverlo es mejor que lo que hacen hoy. Si esas tres cosas son claras y has hablado con al menos 10 a 15 usuarios potenciales que han confirmado que el problema es real y significativo, probablemente estás listo. Si alguna de esas cosas todavía es difusa, invierte primero en la validación previa al MVP.
¿Se puede construir un MVP por menos de £30,000?
En algunos casos, sí — particularmente para herramientas internas con alcance limitado, o para productos donde una parte significativa de la funcionalidad puede ser manejada por servicios de terceros y herramientas sin código en lugar de desarrollo personalizado. Para un SaaS MVP orientado al cliente con autenticación, pagos y un conjunto de funcionalidades significativo, £30,000 típicamente no es suficiente para producir algo viable. Preferimos decírtelo honestamente desde el principio que iniciar un proyecto que se queda sin dinero antes de lanzarse.
¿Qué pasa si mi MVP fracasa?
Un MVP que no logra el ajuste producto-mercado no es un fracaso si te enseñó algo específico y accionable. La pregunta a hacerse es: ¿qué aprendimos y cambia eso nuestra hipótesis? Si la respuesta es «los usuarios quieren esto pero a través de un canal diferente» — eso es valioso. Si la respuesta es «nadie tenía este problema tan gravemente como pensábamos» — eso también es valioso, y te ahorró construir un producto completo que nadie hubiera usado. El único resultado genuinamente malo es gastar dinero en un MVP, no aprender nada de él, y luego gastar más dinero en una V2 basada en suposiciones.
¿Necesito una aplicación móvil para mi MVP?
En la mayoría de los casos, no. Una aplicación web responsiva bien diseñada funciona en los navegadores móviles y se lanza en una fracción del tiempo de una aplicación nativa. Las excepciones son los productos donde las capacidades nativas del dispositivo son genuinamente fundamentales para la propuesta de valor — cámara, GPS, modo sin conexión, notificaciones push que requieren procesos en segundo plano, o integraciones con hardware. Si no estás seguro, opta por la web y añade la versión móvil nativa cuando tengas evidencia de que los usuarios la necesitan.
¿Qué stack tecnológico usan para los proyectos de MVP?
No prescribimos un único stack — seleccionamos en función de los requisitos del producto y las necesidades a largo plazo del cliente. Para la mayoría de los SaaS MVPs basados en web trabajamos con Next.js en el frontend, Node.js o Python en el backend, y PostgreSQL como base de datos principal. Para móvil, usamos React Native o Flutter según la complejidad y la composición del equipo. La infraestructura en la nube se ejecuta en AWS o GCP. Evitamos tecnologías exóticas o de nicho para los MVPs — los stacks probados se construyen más rápido, son más fáciles de contratar y tienen comunidades más grandes cuando algo sale mal.
Construir un MVP es una de las decisiones más importantes que toma un fundador. Hecho bien, te da aprendizaje validado, una base sobre la que construir y evidencia para mostrar a los inversores. Hecho mal, consume tu capital y te deja con un producto que no puedes arreglar fácilmente.
Si estás planeando un MVP y quieres un socio de desarrollo que te diga qué construir y qué eliminar — no solo ejecutar una especificación — nos gustaría hablar. Nuestro proceso de descubrimiento está diseñado precisamente para esto: determinar cuál es realmente el MVP correcto antes de que se escriba una línea de código. Ponte en contacto para iniciar esa conversación.
Habla con nuestro equipo sobre tu proyecto
Trabajamos con empresas en el Reino Unido, EE. UU., EAU, Arabia Saudita, Canadá, Australia y Alemania para desarrollar software personalizado, plataformas SaaS y sistemas marketplace.