Qué Construir en la Primera Versión de Tu App
Hay un patrón fiable en los desarrollos de apps que tienen éxito: la primera versión es embarazosamente simple. Hay un patrón igualmente fiable en los desarrollos de apps que fracasan: la primera versión intenta serlo todo.
Aquí está el marco para decidir qué pertenece a la v1.
Siempre en la V1
Autenticación de usuarios: Los usuarios necesitan crear cuentas, iniciar sesión y recuperar el acceso si olvidan su contraseña. Esto es infraestructura, no una funcionalidad: siempre está en la v1.
La acción principal: Cualquiera que sea la única cosa que hace tu app, la acción única que crea valor para tu usuario, debe estar en la v1. Este es el punto entero del producto. Si tu app es un rastreador de hábitos, el registro de hábitos está en la v1. Si tu app es un marketplace, listar y explorar están en la v1.
Visualización de datos principales: Los usuarios necesitan ver los resultados de sus acciones. Un rastreador de hábitos debe mostrar los hábitos registrados. Un marketplace debe mostrar los listados. Sin este bucle de retroalimentación, los usuarios no pueden verificar que la app funciona.
Estados de error básicos: ¿Qué ocurre cuando algo va mal? Los estados vacíos, los errores de conexión y los estados de carga deben existir, aunque sean simples.
A menudo en la V1 (Depende de tu acción principal)
Notificaciones push: Si tu bucle principal requiere recordar a los usuarios que vuelvan, las notificaciones pertenecen a la v1. Si no, pueden esperar.
Pagos: Solo si la generación de ingresos es central para la hipótesis de la v1. Si estás probando si los usuarios encuentran valor antes de probar si pagarán, aplaza los pagos a la v2.
Perfiles de usuario: Los perfiles básicos (nombre, foto) pertenecen a la v1 si son parte de la acción principal. Los perfiles sociales completos, las páginas públicas y los sistemas de seguidores son casi siempre v2.
Búsqueda y filtrado: Si tu app tiene más de ~20 elementos de contenido, la búsqueda básica pertenece a la v1. Los filtros avanzados suelen ser v2.
Casi nunca en la V1
Funcionalidades sociales: Compartir, seguir, dar me gusta, comentar: todas estas requieren una base de usuarios existente para ser valiosas. En la v1 no tienes base de usuarios. Construye primero la propuesta de valor individual.
Programas de referidos: Necesitas entender la retención antes de invertir en mecánicas de adquisición. Los programas de referidos en la v1 son una optimización prematura.
Paneles de administración: Puedes gestionar los datos iniciales con acceso directo a la base de datos y hojas de cálculo. Un panel de administración completo casi nunca es necesario a escala de la v1.
Paneles de analíticas para usuarios: Date tiempo para entender qué métricas importan antes de integrarlas en el producto.
Integraciones: Las integraciones de terceros (Zapier, Slack, sincronización de calendario, conexiones de CRM) son casi siempre v2 o posteriores. Añaden complejidad de desarrollo significativa y rara vez son críticas para probar tu hipótesis principal.
Modo oscuro: Construye un buen modo. El modo oscuro duplica el esfuerzo de QA de la UI y no añade valor al usuario en la etapa de la v1.
La prueba
Para cada funcionalidad candidata, pregunta: "Si esta funcionalidad no existe, ¿podemos seguir probando si nuestra hipótesis principal es verdadera?"
Si la respuesta es sí, la funcionalidad no está en la v1. Esta prueba es más fiable que cualquier marco o regla general.
Valor principal vs. funcionalidades de apoyo
Antes de decidir qué entra en la v1, necesitas separar dos tipos de funcionalidades que los fundadores confunden constantemente.
El valor principal es lo único que hace tu app y que ninguna hoja de cálculo, chat de grupo o competidor ya hace lo bastante bien para tu usuario. Es la razón por la que alguien abre tu app en lugar de no hacer nada. Quítalo y no hay producto.
Las funcionalidades de apoyo hacen que el valor principal sea más fácil, rápido o agradable de usar. Importan, pero solo porque el valor principal ya existe. Quita una funcionalidad de apoyo y el producto es peor, no desaparece.
Una forma sencilla de distinguirlos: si describieras tu app a un desconocido en una sola frase, el valor principal es la parte que no puedes omitir. Todo lo que solo mencionarías en la segunda o tercera frase es una funcionalidad de apoyo.
El error es tratar a ambos como igual de urgentes. No lo son. En la v1, construyes el valor principal con un alto nivel de calidad y las funcionalidades de apoyo con un nivel de "suficiente para no estorbar", o las eliminas por completo. Los fundadores que pulen las funcionalidades de apoyo antes de que el valor principal funcione están decorando una habitación que nadie ha aceptado alquilar todavía.
Por qué la autenticación pertenece a la v1 pero compartir en redes sociales normalmente no
Estas dos funcionalidades están en extremos opuestos de la decisión de la v1, y entender por qué te enseña el principio completo.
La autenticación está en la v1 porque es el suelo sobre el que se sostiene el producto. Los usuarios necesitan crear una cuenta, volver a iniciar sesión y recuperar el acceso cuando olvidan su contraseña. Sin ella, no puedes guardar los datos de nadie, no puedes distinguir a un usuario de otro, y no puedes medir si alguien vuelve. No es una funcionalidad que estés probando: es la fontanería que te permite probar todo lo demás. Las herramientas modernas de backend como Firebase y Supabase incluyen la autenticación de serie, así que cuesta poco incluirla y lo rompe todo omitirla.
Compartir en redes sociales normalmente espera a la v2 porque su valor depende de algo que la v1 todavía no tiene: otras personas. Seguir, compartir dentro de la app, perfiles públicos y feeds de actividad solo crean valor una vez que tienes una base de usuarios produciendo contenido que valga la pena seguir. El día del lanzamiento no tienes ninguno. Construir un grafo social antes de tener usuarios es construir un salón de fiestas antes de invitar a nadie.
Hay una razón más profunda para aplazarlo. Las funcionalidades sociales cambian lo que estás probando. Si tu app solo tiene valor cuando los amigos de un usuario también están en ella, ya no puedes medir si una sola persona encuentra útil el producto por su cuenta. Ese valor para un único usuario — ¿una persona, sola, obtiene algo de esto? — es la señal más limpia de product-market fit que jamás conseguirás. Las mecánicas sociales la enturbian. Demuestra primero el valor individual, y luego añade los efectos de red encima.
Usa Jobs to Be Done para decidir
El marco más útil para separar lo principal de lo accesorio es Jobs to Be Done, popularizado por el difunto profesor de Harvard Clayton Christensen. Su idea central es simple: los clientes no compran productos, los "contratan" para avanzar en un trabajo concreto de su vida.
Christensen lo ilustró con una cadena de comida rápida que intentaba vender más batidos. La investigación tradicional sobre sabores y datos demográficos de los clientes no llevó a ninguna parte. El avance llegó al preguntar qué trabajo estaban contratando los clientes que hiciera el batido. Una gran parte de los batidos se compraban temprano por la mañana, por personas que iban al trabajo y querían algo que ocupara un trayecto largo y aburrido: que se pudiera sostener con una mano, lento de terminar y lo bastante saciante para aguantar el hambre hasta el mediodía. La cadena hizo el batido más espeso para que durara todo el trayecto. No estaban vendiendo un postre. Estaban vendiendo un mejor camino al trabajo.
Para un fundador de apps, el marco convierte cada decisión de funcionalidad en una sola pregunta: ¿esta funcionalidad ayuda directamente al usuario a terminar el trabajo para el que contrató mi app?
Para aplicarlo:
- Escribe el trabajo, no la funcionalidad. "Ayudar a un freelancer a cobrar más rápido" es un trabajo. "Añadir una pestaña de pagos" es una funcionalidad. Empieza por el trabajo.
- Identifica el camino crítico del trabajo. ¿Cuál es la secuencia más corta de pasos que lleva al usuario de "tengo este trabajo" a "el trabajo está hecho"? Ese camino es tu v1.
- Evalúa cada otra funcionalidad contra el trabajo. Si una funcionalidad no hace avanzar al usuario por ese camino, es una funcionalidad de apoyo en el mejor de los casos y una distracción en el peor. Espera.
El marco corta el sesgo del fundador porque te obliga a argumentar desde el objetivo del usuario, no desde tu lista de deseos.
Con qué lanzó Instagram vs. en qué se convirtió
Instagram es el ejemplo documentado más claro de una v1 deliberadamente estrecha, y de cuánto se puede añadir después una vez que el núcleo funciona.
La app ni siquiera empezó siendo Instagram. Los fundadores Kevin Systrom y Mike Krieger construyeron primero Burbn, una app de check-in de ubicación con muchas funcionalidades. Costaba que funcionara. Notaron que a los usuarios les importaba sobre todo una cosa — compartir fotos — así que recortaron casi todo lo demás y reconstruyeron en torno a ese único comportamiento.
Cuando Instagram se lanzó el 6 de octubre de 2010 como una app solo para iPhone, hacía aproximadamente un trabajo: capturar una foto, aplicar un filtro y compartirla. La primera versión tenía filtros, "me gusta", comentarios y un feed cronológico simple. Eso era esencialmente todo el producto. Los filtros importaban porque permitían que las fotos corrientes de móvil se vieran bien, lo que eliminaba la principal razón por la que la gente dudaba en publicar.
Casi todo lo que la gente asocia hoy con Instagram llegó después, una vez probado el núcleo:
- El vídeo llegó en junio de 2013.
- Los mensajes directos llegaron en diciembre de 2013.
- Las Stories se lanzaron en agosto de 2016.
- Las funcionalidades de compras y los Reels llegaron ambos en 2020.
Nada de eso estaba en la v1. Los fundadores lanzaron un trabajo bien hecho y luego se ganaron el derecho a añadir el resto. Si hubieran intentado lanzar con stories, mensajería, vídeo y compras a la vez, habrían pasado años construyendo antes de averiguar si alguien siquiera quería compartir una foto con filtro.
Otros ejemplos documentados de primeras versiones intencionadamente simples
Instagram no es una excepción. El patrón se repite en algunos de los productos de mayor éxito jamás creados.
Amazon se lanzó como una librería y nada más. Cuando abrió el 16 de julio de 1995, Amazon solo vendía libros. Jeff Bezos ha dicho que eligió los libros de forma deliberada: había muchísimos más títulos impresos de los que cualquier tienda física podía tener en stock, la demanda era amplia y el precio unitario era bajo. La "tienda de todo" llegó después: Amazon no empezó a ofrecer música hasta 1998, y el enorme catálogo creció a partir de ahí. La primera versión era una sola categoría, bien ejecutada.
Airbnb empezó con un solo colchón inflable y una página web básica. En 2007, los diseñadores Brian Chesky y Joe Gebbia no podían pagar el alquiler, así que durante un congreso de diseño con todo agotado en San Francisco pusieron colchones inflables en su apartamento, montaron un sitio sencillo llamado Air Bed and Breakfast y cobraron a los huéspedes por un sitio donde dormir y un desayuno casero. No había búsqueda global, ni reserva instantánea, ni sistema de reseñas, ni plataforma de pagos. Había tres huéspedes sobre un colchón inflable. Todo lo que hoy hace de Airbnb una plataforma se añadió después de que la idea básica — que desconocidos pagarán por quedarse en tu casa — resultara ser cierta.
La lección en los tres casos es la misma que debería seguir tu propia v1: elige el único trabajo para el que existe tu producto, construye esa única cosa lo bastante bien como para que la gente vuelva, y gánate cada funcionalidad que añadas después con evidencia en lugar de con ambición.