Un MVP de app es la versión más pequeña que resuelve un problema real y ya se puede publicar en tienda: 1 flujo principal, 3 a 5 pantallas y 6 a 12 semanas de desarrollo. En Colombia, los rangos de referencia del mercado ubican un MVP funcional entre $15.000.000 y $45.000.000 COP, frente a los $80.000.000 COP o más de una app completa.
La diferencia entre las dos cifras no está en la calidad del código: está en cuántas funciones decide construir antes de tener el primer usuario real. Esta guía explica cómo recortar el alcance sin quedarse con un producto inútil.
Qué es un MVP y qué NO es
Un MVP (producto mínimo viable) es una app publicable que resuelve un solo problema, de punta a punta, para un solo tipo de usuario. La palabra que más se ignora es viable: si el usuario no logra completar la tarea principal sin ayuda, no tiene un MVP, tiene una demostración. El recorte se hace en cantidad de funciones, nunca en la calidad del flujo que sí incluye.
Lo que un MVP no es:
- No es una app a medias. Tres pantallas impecables valen más que quince a medio terminar.
- No es un prototipo en Figma. Eso es validación previa, y sirve, pero no genera usuarios ni reseñas.
- No es una app fea. En tiendas saturadas, el diseño es parte de la funcionalidad; por eso vale la pena entender el costo de diseño UX/UI en Colombia antes de recortarlo.
- No es gratis de mantener. Desde el día del lanzamiento empieza el reloj de actualizaciones de sistema operativo y soporte.
Un ejemplo concreto de alcance acotado: Rankiamos, mi rank tracker SEO publicado en App Store (14.99 USD, compra única), gira alrededor de una sola tarea: ver la posición de una palabra clave por ciudad y dispositivo. Todo lo demás (conexión con Google Search Console, análisis con IA) se sumó alrededor de ese núcleo, no antes.
Cómo elegir la funcionalidad núcleo
La funcionalidad núcleo es la única acción por la que un desconocido descargaría la app hoy. Para encontrarla, escriba en una frase qué hace el usuario y qué obtiene: abre la app, escribe una palabra clave, ve en qué posición está. Si necesita dos frases, todavía tiene dos productos mezclados.
Un método que funciona en la práctica:
- Liste todas las funciones que imagina sin filtro. Salen entre 25 y 60.
- Marque una sola como núcleo. Solo una. Si no puede elegir, el problema no está definido.
- Clasifique el resto en tres cajas: soporta el núcleo, es cómodo, o es un producto distinto.
- Construya el núcleo y su soporte mínimo. Todo lo demás pasa al backlog fechado.
El soporte mínimo casi siempre es lo mismo: registro o ingreso, la pantalla del núcleo, un estado vacío bien resuelto, ajustes básicos y el canal de contacto. Con eso ya se puede publicar. Si duda de si su caso necesita app o le basta la web, primero resuelva esa pregunta con la guía ¿su negocio necesita una app o basta con la página web?.
Preguntas que reducen el alcance en minutos
- ¿Qué pasa si esta función no existe en la versión 1? Si la respuesta es que el usuario igual logra su objetivo, fuera.
- ¿Cuántos usuarios la usarían la primera semana? Si es un porcentaje pequeño, fuera.
- ¿Se puede resolver manualmente por WhatsApp o correo los primeros dos meses? Si sí, fuera del código.
- ¿Es un requisito de tienda o de ley (privacidad, borrado de cuenta, permisos)? Eso nunca se recorta.
El error de querer lanzar con todo
El patrón más costoso en proyectos de app es el alcance en abanico: se quiere versión iOS y Android, panel administrativo web, chat interno, notificaciones segmentadas, pasarela de pagos, reportes y multiidioma en la versión 1. Eso multiplica el presupuesto por tres o cuatro y estira el plazo de 10 semanas a 8 o 10 meses, con un detalle grave: todo se decide sin un solo dato de uso real.
Los costos de ese error son acumulativos:
- Costo de oportunidad. Ocho meses sin usuarios son ocho meses sin aprender ni cobrar.
- Costo de mantenimiento. Cada función construida hay que probarla en cada actualización de iOS y Android. El costo de mantener una app escala con el número de funciones, no con el de usuarios.
- Costo de borrar. Descartar lo que nadie usó también se paga en horas.
- Costo de foco. Una app que hace ocho cosas es imposible de explicar en la ficha de la tienda, y eso golpea directo el posicionamiento en las tiendas (ASO).
Alcance típico de un MVP y su plazo
Un MVP nativo de una plataforma se entrega en 6 a 12 semanas y, en rangos de referencia del mercado colombiano, cuesta entre $15.000.000 y $45.000.000 COP, dependiendo de si necesita servidor propio, pagos e integraciones. Estas son las piezas y su peso real dentro del cronograma real de desarrollo:
| Módulo del MVP | Semanas | Rango de referencia (COP) | ¿Va en la v1? |
|---|---|---|---|
| Descubrimiento y definición del núcleo | 1 – 2 | $2.000.000 – $5.000.000 | Sí, siempre |
| Diseño UX/UI de 4 – 6 pantallas | 1 – 2 | $3.000.000 – $8.000.000 | Sí |
| Flujo núcleo + ingreso de usuario | 3 – 5 | $8.000.000 – $20.000.000 | Sí |
| Backend, base de datos y API | 2 – 4 | $6.000.000 – $18.000.000 | Solo si hay datos compartidos |
| Pagos dentro de la app | 1 – 2 | $3.000.000 – $9.000.000 | Solo si cobra desde el día 1 |
| Notificaciones push segmentadas | 1 – 2 | $2.500.000 – $7.000.000 | No, versión 2 |
| Panel administrativo web | 3 – 6 | $9.000.000 – $25.000.000 | No, use consultas directas |
| Publicación en tienda y fichas | 0,5 – 1 | $1.500.000 – $4.000.000 | Sí |
A eso se suman las cuentas de desarrollador, que son costos oficiales y públicos: el Apple Developer Program cuesta 99 USD al año y la cuenta de Google Play Console 25 USD por única vez, según los precios publicados por Apple y Google. Los requisitos completos están en la guía de cómo publicar una app en App Store y Google Play, y el desglose de presupuesto total en cuánto cuesta desarrollar una app en Colombia.
Dos decisiones que recortan semanas sin recortar valor: lanzar en una sola plataforma (la de sus usuarios que pagan) y elegir bien el stack. Comparar app nativa, híbrida o PWA antes de firmar suele ahorrar más presupuesto que negociar la tarifa por hora.
Cómo validar antes de escribir código
Se puede validar la demanda con 1 a 3 semanas de trabajo y menos de $3.000.000 COP, sin una línea de código de app. La meta no es adivinar si la idea gusta: es medir si alguien deja su contacto, paga una preventa o usa un proceso manual equivalente.
Cuatro pruebas ordenadas de menor a mayor esfuerzo:
- Landing de una sola oferta con formulario o botón de lista de espera. Sirve para medir intención real; la diferencia práctica entre esto y un sitio completo está en landing page vs página web.
- Tráfico pagado de prueba. Con $800.000 a $2.000.000 COP en publicidad en Google Ads obtiene suficientes clics para leer una tasa de registro, no solo una impresión.
- Prototipo clicable en manos de 8 a 12 usuarios reales. Con esa cantidad ya aparecen los problemas de flujo repetidos.
- Operación manual (concierge). Preste el servicio a mano por WhatsApp durante 3 o 4 semanas. Ahí descubre las excepciones que ningún documento de requisitos incluye.
Regla de decisión: si con tráfico pagado no consigue que al menos 5 % a 10 % de las visitas deje su correo o pague una preventa, el problema no es la app, es la propuesta. Construir el MVP en ese punto solo hace más caro el diagnóstico.
Qué medir desde el día 1
Un MVP sin medición no es un experimento, es una apuesta. La instrumentación mínima se instala antes del lanzamiento, no después, y debe responder tres cosas: cuánta gente activa el núcleo, cuánta vuelve y cuánto cuesta traerla.
| Métrica | Qué responde | Referencia sana en un MVP |
|---|---|---|
| Activación (llegó al núcleo) | ¿El flujo se entiende solo? | 40 % – 60 % de los registros |
| Retención día 7 | ¿Resuelve algo recurrente? | 15 % – 25 % |
| Retención día 30 | ¿Hay producto de verdad? | 8 % – 15 % |
| Conversión a pago | ¿El precio es coherente? | 1 % – 5 % de los activos |
| CAC por instalación pagada | ¿El canal es sostenible? | Menor al ingreso por usuario |
| Reseñas y calificación en tienda | ¿Qué frena la descarga? | 4,5★ o más para competir |
Etiquete cada campaña y cada enlace desde el inicio con parámetros UTM; sin eso no sabrá qué canal trajo a los usuarios que se quedaron. Y trate el proyecto con la disciplina de cualquier inversión de marketing, mirando los KPIs de CAC, ROAS y LTV en lugar del número de descargas, que es la métrica más fácil de inflar y la más inútil.
El modelo de cobro también es parte del MVP
Definir cómo cobra desde la versión 1 cambia el alcance técnico. Un modelo de compra única evita construir gestión de renovaciones, recuperación de pagos fallidos y estados de suscripción, que es trabajo real de semanas. Es la decisión que tomé en mis dos apps publicadas: Chately (CRM de WhatsApp con IA, 39.99 USD) y Rankiamos (14.99 USD), ambas de compra única y disponibles en iPhone, iPad, Apple Watch y Mac. La contrapartida es explícita: sin suscripción no hay ingreso recurrente, así que el crecimiento depende de nuevos compradores y de nuevas versiones que justifiquen otra compra.
Los términos oficiales de ambas tiendas cobran una comisión estándar del 30 % sobre ventas digitales, con 15 % para desarrolladores pequeños (el App Store Small Business Program de Apple y el esquema equivalente de Google Play para el primer millón de dólares anuales). Ese porcentaje debe estar dentro del precio antes de lanzar, no después. El análisis por modelo está en cómo monetizar una app.
Del MVP a la versión 2
La versión 2 se define con datos, no con la lista de deseos original. La regla práctica: espere 6 a 10 semanas de uso real o unos 300 usuarios activos, y ordene el backlog por lo que la gente intentó hacer y no pudo. Tres señales concretas y su lectura:
- Activación baja pero retención buena: el problema es el arranque (registro, estado vacío, primer valor), no el producto.
- Activación buena y retención día 7 baja: resolvió una curiosidad, no un hábito. Ahí se justifican recordatorios o notificaciones.
- Retención buena y conversión a pago baja: revise precio, momento del cobro y qué queda del otro lado del muro.
Priorice en ciclos cortos: una función grande o dos pequeñas cada 4 a 6 semanas, con una actualización publicada en tienda cada mes. Publicar seguido tiene un beneficio adicional: la frecuencia de actualizaciones y el flujo de reseñas ayudan al posicionamiento en tienda.
Si quiere ver el resultado de este enfoque, puede revisar mis apps en producción —Chately, Rankiamos y atiendy, esta última próximamente— o aterrizar el alcance de su MVP en desarrollo de apps en Colombia. Definir bien el núcleo en la primera semana es lo que separa un lanzamiento en 3 meses de un proyecto que nunca sale.
