La respuesta honesta, antes del detalle
De los negocios que llegan a nosotros con esta pregunta exacta, alrededor de ocho de cada diez necesitan primero una buena web que funcione bien en el móvil, y una aplicación más adelante o nunca. Esa es la versión corta, y preferimos dársela en el primer párrafo en lugar de guardarla para el final, porque equivocarse en esta decisión sale caro de una forma que luego cuesta mucho deshacer. Todo lo que viene a continuación es simplemente la aritmética que le permitirá llegar a su propia respuesta, que puede ser perfectamente la contraria.
Ayuda mucho fijarse en la pregunta que hay debajo de la pregunta. Casi nadie quiere una aplicación por sí misma: lo que quiere es llegar a sus clientes en ese teléfono que no sueltan en todo el día, y en algún momento del camino alguien le contó que llegar a la gente en el móvil significa estar en la tienda de aplicaciones. No es así, porque una web que se reordena para caber en una pantalla pequeña ya está en ese teléfono, ya está a un toque de distancia y ya llega a personas a las que la aplicación no llegará jamás.
Como estas tres palabras se usan de forma bastante suelta en casi cualquier reunión, conviene fijar aquí qué significa cada una. Una web es un conjunto de páginas que cualquiera abre en un navegador tocando un enlace, sin nada que instalar y sin nada que aceptar. Una aplicación es un programa que la persona tiene que buscar en la App Store de Apple o en Google Play, descargar y mantener en su teléfono. Y responsive, que en español decimos adaptable, quiere decir que esa misma web se recoloca sola según la pantalla en la que aterriza, de modo que el menú se convierte en una lista desplegable y las columnas se apilan en el móvil, mientras la gestoría sigue viendo la versión ancha en el ordenador de la oficina.
Tres números deciden esto, y ninguno de ellos es una lista de funciones. El primero es su tasa de instalación, es decir, cuánta de la gente que ve su negocio en el móvil va a poner de verdad su aplicación dentro del teléfono. El segundo es lo que esa cosa cuesta mantener viva en el segundo y el tercer año, mucho después de las fotos del lanzamiento. El tercero es con qué frecuencia un solo cliente la abriría, porque ese dato por sí solo separa las aplicaciones que sobreviven de las que se borran en silencio el día que el móvil se queda sin espacio. Vamos a recorrer los tres, y si al terminar los números apuntan sencillamente a construir bien la web, se lo diremos en voz alta en vez de venderle el proyecto grande.
Lo que una web hace mejor que una aplicación
La mayor ventaja de una web está en lo único que no le pide a nadie: permiso. No existe ningún paso de instalación, así que un mismo enlace funciona en un iPhone, en un Android, en un portátil, en el ordenador compartido de la oficina y en la tableta que usa la madre de alguien. Puede meter ese enlace en un mensaje de texto, en un ticket de compra, en el lateral de una furgoneta o en un correo, y cada persona que lo toque llegará a su negocio en un par de segundos, sin cuenta de tienda, sin contraseña y sin ningún aviso de almacenamiento por medio.
Luego está la búsqueda, que es la parte que casi todo el mundo subestima. Una web puede aparecer cuando alguien que jamás ha oído hablar de usted escribe en Google lo que necesita esa tarde, y ese desconocido se convierte en cliente sin que usted haya pagado por presentarse. Ninguna búsqueda dentro de una tienda de aplicaciones va a hacer eso por una panadería o por una clínica dental, sencillamente porque nadie abre Google Play a ver qué dentista nuevo hay cerca. Si su problema real es que le encuentre gente que todavía no le conoce, el trabajo está en la web y en cómo la damos a conocer, no en una ficha de tienda.
Hay otra diferencia que se nota cada semana en un negocio de verdad: en una web los cambios están publicados en minutos. Sube el precio del menú del día, se agota una talla, cambia el horario de agosto o entra un festivo local, y usted lo edita y ya está hecho para todo el mundo. Cuando el catálogo, las tarifas o el stock se mueven, esa velocidad deja de ser una comodidad y pasa a ser dinero.
También hay una sola cosa que construir y una sola cosa que pagar, porque esas mismas páginas sirven a todos los dispositivos, incluido el ordenador de mesa desde el que trabaja su contable. Y sobre todo, una web es la manera barata de comprobar si la idea tiene clientes antes de que nadie se comprometa con una obra mayor: si la versión sencilla no consigue reservas, pedidos ni llamadas, una aplicación tampoco lo hará, solo que le habrá costado cinco o diez veces más descubrirlo.
Lo que una aplicación sí le aporta de verdad
Dicho todo lo anterior, hay cuatro ventajas de una aplicación que son reales y que no admiten discusión.
- Un icono permanente en la pantalla de inicio, que es el equivalente digital de un local en la calle principal.
- Las notificaciones, que llegan al cliente justo en un momento en el que no estaba pensando en usted.
- Funcionar sin cobertura, con los datos guardados dentro del propio teléfono y enviados solos cuando vuelve la señal.
- El acceso profundo al hardware del móvil, es decir la cámara, el GPS, el Bluetooth, el sensor de huella y la lectura de códigos de barras, todo ello de una manera más estable y más completa de lo que un navegador permite.
Una notificación, dicho en cristiano, es un mensaje corto que aparece en la pantalla bloqueada sin que la persona abra nada. Es el único canal que le deja interrumpir a alguien con educación, y por eso vale dinero. Lo que vemos en la práctica es que entre el 40 y el 60 por ciento de las instalaciones en Android aceptan recibirlas, y una proporción bastante menor en iPhone, donde la persona tiene que decir que sí de forma explícita. De quienes las aceptan, un mensaje bien elegido y bien puesto en el tiempo mueve a actuar a entre el 3 y el 10 por ciento de la gente, frente a entre el 1 y el 3 por ciento del mismo mensaje enviado por correo electrónico.
A quién le encajan de verdad esas cuatro ventajas es una lista corta y bastante reconocible: repartidores que van marcando entregas, técnicos de campo que rellenan partes en un sótano o en una nave sin señal, personal de almacén que escanea códigos todo el día, programas de fidelización con puntos y cupones, y cualquier servicio que un mismo cliente toca todas las semanas. Si su negocio está en esa lista, la conversación cambia por completo y merece la pena hablar en serio de construir la aplicación como toca.
Ahora la parte incómoda, dicha con cariño: la frase "a nuestros clientes les encantaría tener una app" es un deseo, no una de las cuatro razones. Un deseo no paga el segundo año de mantenimiento, y el segundo año llega siempre. Cuando en una reunión pedimos que la motivación se traduzca a una de esas cuatro ventajas y no aparece ninguna, casi siempre estamos delante de un proyecto que va a terminar abandonado con la factura ya pagada.
La barrera de la instalación que nadie mete en el presupuesto
Hagamos la cuenta despacio, porque es la que suele cambiar de opinión a la gente. Imagine 1.000 personas que llegan a su negocio desde el móvil y a las que se les pide instalar la aplicación. De esas mil, unas 40 completan la instalación y la abren. Otras 110 tocan el botón de instalar y se quedan por el camino, en la contraseña de la tienda, en el aviso de espacio o simplemente porque la descarga tardaba y sonó el teléfono. Y las 850 restantes siguen a lo suyo usando la web móvil, que es lo que querían desde el principio. Eso es una tasa de instalación de entre el 2 y el 6 por ciento según lo conocida que sea la marca.
Hay un segundo dato que conviene tener claro antes de contar con la tienda como canal de captación: la búsqueda dentro de la tienda casi no trae desconocidos. Prácticamente todas las instalaciones que podemos rastrear vienen de alguien que ya conocía el negocio por un cartel, un ticket, un correo, una recomendación o un resultado de Google, y que fue a la tienda a buscarlo por su nombre. Nadie descubre su marca navegando por Google Play, del mismo modo que nadie descubre una cafetería nueva leyendo la guía telefónica.
De ahí sale la conclusión que de verdad necesita: una aplicación es una herramienta para conservar a los clientes que ya tiene, mientras que una web es la herramienta para encontrar a los que todavía no tiene. Las dos pueden convivir, pero el orden en que se construyen no es indiferente, y construir primero la que solo sirve para retener cuando aún no hay a quién retener es el error más caro de todo este terreno. Si lo que le atrae de la aplicación es poder avisar a su gente al instante, empiece por leer cómo funcionan los avisos y las notificaciones antes de comprometer el presupuesto entero.
Lo que cuesta construir cada opción
Estas son las cuatro bandas que presupuestamos habitualmente en Linkysoft, en dólares y para proyectos hechos bien, no para plantillas montadas en una tarde. Antes de la lista conviene traducir dos palabras que aparecen en ella. Nativa quiere decir que la aplicación se programa dos veces, una expresamente para iPhone y otra expresamente para Android, porque los dos teléfonos no entienden el mismo código. Y una aplicación web es una web en la que la gente entra con usuario y contraseña para trabajar, no solo para leer.
- Una web adaptable de presentación: de 5.000 a 12.000 USD, entregada en 4 a 8 semanas.
- Esa misma web con reservas y pago en línea: de 12.000 a 25.000 USD y de 8 a 12 semanas, porque el dinero y el calendario obligan a un nivel de pruebas distinto.
- Una aplicación web con cuentas de usuario, roles y paneles, esas pantallas que resumen de un vistazo cómo va el negocio: entre 25.000 y 60.000 USD y de 12 a 20 semanas.
- Dos aplicaciones móviles nativas más el servidor que las alimenta: de 60.000 a 150.000 USD y de 20 a 28 semanas, porque cada pantalla se construye dos veces y se prueba en decenas de dispositivos distintos.
Lo que mueve cada presupuesto dentro de su banda son siempre las mismas cuatro cosas: cuántas pantallas hay, cuántos tipos de usuario distintos entran, si hay pagos y con cuántos sistemas ajenos tiene que hablar el conjunto.
Una duda razonable en este punto es por qué dos plataformas no cuestan exactamente el doble que una. La respuesta es que el diseño, el servidor, la definición del producto y el plan de pruebas se comparten, mientras que el código de las pantallas no se comparte en absoluto, así que la segunda plataforma suma en la práctica entre un 60 y un 80 por ciento sobre la primera. En otras palabras, dos aplicaciones nativas salen por entre 1,6 y 1,8 veces lo que sale una.
Seamos justos también con los marcos multiplataforma, esas herramientas que permiten escribir el grueso del código una sola vez y publicarlo en los dos sistemas. Funcionan y se usan mucho, y normalmente ahorran entre un 20 y un 35 por ciento de la construcción. Ahora bien, ese ahorro se encoge cuando la aplicación se apoya con fuerza en la cámara, en los mapas o en el Bluetooth, porque justo esas partes acaban escribiéndose a medida para cada plataforma y hay que probarlas dos veces igualmente.
Hay una línea del presupuesto que la gente no ve y que conviene sacar a la luz: el servidor, la base de datos y la lógica que hay detrás cuestan lo mismo tanto si delante hay una web como si hay una aplicación. Los pedidos, las cuentas, los pagos y los informes viven ahí, no en el teléfono, así que cuando alguien compara "web contra app" está comparando en realidad dos fachadas de un mismo sistema por dentro. Esa es la parte que sobrevive a los cambios de moda, y por eso es donde recomendamos poner el dinero primero.
Las facturas que llegan después del lanzamiento
Los costes fijos de las tiendas son públicos y son pequeños: 99 USD al año por la cuenta de desarrollador de Apple y 25 USD una sola vez en Google Play. La comisión, en cambio, no es pequeña. Sobre cualquier cosa digital que se venda dentro de la aplicación, suscripciones, créditos, contenidos o funciones de pago, la tienda se queda entre el 15 y el 30 por ciento, frente a aproximadamente el 2 o el 3 por ciento que cuesta cobrar con tarjeta en su propia web. Si vende suscripciones por valor de 100.000 USD al año, la diferencia entre esos dos porcentajes está entre 12.000 y 28.000 USD anuales, es decir, más o menos el precio de una web de pedidos entera, y esa factura se repite cada año.
Después está el mantenimiento, que es la partida que más presupuestos rompe porque casi nunca se anticipa. Calcule entre el 15 y el 25 por ciento del coste de construcción cada año, y no porque nadie quiera cobrarle de más, sino porque Apple y Google publican una versión mayor de su sistema operativo cada año y una aplicación que no se toca deja de ser compatible. Sobre una construcción de 80.000 USD eso son entre 12.000 y 20.000 USD anuales que hay que tener en el plan desde el primer día.
Ligado a lo anterior viene un dato que decimos siempre en la primera reunión: una aplicación que nadie toca durante 18 a 24 meses normalmente se rompe o acaba retirada de la tienda, mientras que una web abandonada durante el mismo tiempo sigue cargando y sigue trayendo clientes. Esa asimetría es la razón por la que una aplicación es un compromiso continuo y una web es más parecida a un activo, y merece la pena entender bien qué incluye el mantenimiento antes de firmar nada.
Junto a eso hay un coste de personas que nadie presupuesta, porque dos tiendas significan dos colas de revisión, dos reglamentos que cumplir y dos maneras distintas de recibir un rechazo. Una primera publicación tarda normalmente entre 24 y 48 horas en pasar la revisión, y en nuestra experiencia aproximadamente una de cada tres aplicaciones vuelve rechazada al menos una vez antes de ser aceptada, por un permiso mal explicado, un texto legal que falta o una captura de pantalla que no encaja. Cada rechazo son horas de alguien de su equipo, no solo del proveedor.
Y una última consideración que no es económica pero acaba siéndolo: en el momento en que guarda cuentas de usuario, ubicaciones o datos de pago, su deber de cuidado sube de nivel, y con él la obligación de proteger los datos de sus clientes con algo más que buena voluntad. Eso vale para la web y para la aplicación, con la diferencia de que la aplicación suele guardar más cosas dentro del teléfono y, por tanto, hay más superficie que cuidar.
Velocidad de cambio: minutos frente a días
Este apartado por sí solo resuelve la duda para la mayoría de comercios y restaurantes. Un precio, un plato, una talla o un horario cambian en una web y todos los visitantes, absolutamente todos, ven la versión nueva en menos de diez minutos. No hay nada que aprobar y no hay nadie a quien esperar.
El mismo cambio en una aplicación tiene que pasar por la revisión de la tienda, que suele llevar de 24 a 48 horas y en algunos casos hasta una semana, y después llega solo al 50 o 70 por ciento de los usuarios durante la primera semana, con una cola que se alarga meses porque hay gente que no actualiza nunca nada. Es decir, incluso una corrección de precio tarda un día o más en llegar a alguien, y semanas en llegar a todos.
La consecuencia práctica es más seria de lo que parece: durante un tiempo usted está funcionando con dos versiones de su propio negocio a la vez, la nueva y la que siguen viendo los que no han actualizado. Por eso, en una aplicación, un cambio de precio no es realmente un cambio, es una migración, con su plan, su periodo de convivencia y su manera de tratar al cliente que abre la versión antigua y ve la tarifa del mes pasado.
La regla práctica es sencilla: si sus precios, su stock o sus contenidos se mueven cada semana, la web gana por este punto solo, sin necesidad de discutir ningún otro. Y si se mueven cada día, como en la hostelería o en el comercio, la discusión ni siquiera debería empezar.
La opción intermedia que casi nadie le enseña
Entre la web y la aplicación hay una tercera cosa que rara vez sale en las reuniones comerciales, seguramente porque se factura menos: la web instalable en la pantalla de inicio, que en el sector se conoce como aplicación web progresiva. Dicho sin tecnicismos, es su web de siempre preparada para que el cliente pueda añadirla a la pantalla de inicio con un par de toques, de forma que tiene su propio icono, se abre a pantalla completa sin la barra del navegador, recuerda quién es esa persona, sigue funcionando cuando la señal se cae y, en los teléfonos modernos, también puede enviar notificaciones.
El coste y el plazo son la parte agradable: normalmente entre 2.000 y 5.000 USD sobre una web que ya existe, con una a tres semanas de trabajo. No hace falta cuenta de desarrollador, no hay cola de revisión, no hay rechazos y no hay comisión sobre lo que venda. Publica cuando quiere, corrige un precio en diez minutos y le sigue apareciendo a la gente en Google, cosa que una aplicación no hace.
Conviene ser igual de claro con lo que no cubre. Se queda corta cuando el trabajo depende mucho del Bluetooth o de la localización en segundo plano, tiene limitaciones en algunos flujos de pago según el dispositivo, el usuario tiene que saber que puede añadirla a la pantalla de inicio, y hay un hecho que a veces pesa en la decisión y hay que decirlo: no aparece en las tiendas de aplicaciones, así que si su cliente le va a buscar ahí por costumbre, no le encontrará.
La secuencia que recomendamos a nuestros clientes es esta, y funciona: publique la web instalable, mire los números durante un trimestre completo, y decida después lo de la aplicación nativa con datos en la mano en lugar de con opiniones. Si en tres meses ve que hay un grupo real de clientes que la abre cada semana, que acepta las notificaciones y que vuelve, ya tiene la justificación para la inversión grande. Y si no lo ve, se ha ahorrado entre 60.000 y 150.000 USD por el precio de tres semanas de trabajo.
Cinco preguntas que lo deciden
Cuando alguien nos pide una respuesta rápida, le hacemos estas cinco preguntas. Se contestan en cinco minutos y tienen más valor que cualquier comparativa de funciones.
- ¿Con qué frecuencia abriría esto un solo cliente? Cada semana, es decir unas cincuenta veces al año, es un sí. Una vez al mes, que son doce veces al año, es un quizá que solo se convierte en sí cuando cada una de esas doce visitas vale dinero de verdad. Unas pocas veces al año es un no rotundo, porque por debajo de una vez al mes su aplicación es lo primero que se borra cuando el teléfono se queda sin espacio.
- ¿El trabajo principal tiene que funcionar sin cobertura ninguna? Piense en un sótano, un ascensor, una granja, un almacén metálico o una furgoneta en movimiento. Si la respuesta es que sí y de forma habitual, la aplicación empieza a ganar puntos de verdad.
- ¿La tarea central necesita de verdad la cámara, el GPS, el Bluetooth o la huella? No como añadido simpático, sino como la cosa en sí: escanear cien códigos al día, medir una ruta, conectar con un aparato, firmar una entrega.
- ¿Un mensaje que llega en menos de un minuto vale dinero contante y sonante? Un reparto que sale, una plaza que se acaba de liberar, una subasta que cierra. Si el valor del aviso caduca en minutos, ese es el argumento más fuerte a favor de la aplicación.
- ¿Puede financiar el segundo y el tercer año al 15 o 25 por ciento del coste de construcción, cada año, sin que le duela? Si esa cifra no cabe en el presupuesto anual con naturalidad, la respuesta ya está dada.
La puntuación es tan simple como suena: tres o más síes claros y la aplicación se ha ganado su sitio, así que hay que construirla bien. Menos de tres y la recomendación es construir la web, guardarse el dinero y volver a hacerse estas mismas preguntas dentro de seis meses, cuando tenga datos propios en lugar de suposiciones.
Tres situaciones reales y lo que recomendamos
El restaurante que pagaba comisión a un portal de reparto
El punto de partida era que el portal de reparto se llevaba entre el 25 y el 30 por ciento de cada pedido, lo que en un pedido de 20 USD son unos 5 USD que se van. Con esa cuenta encima de la mesa, una web propia de pedidos con pago en línea entra en la banda de 12.000 a 25.000 USD que dábamos más arriba, así que a 5 USD ahorrados por pedido se amortiza entre los 2.400 y los 5.000 pedidos, es decir, entre dos y cuatro meses al ritmo de cuarenta pedidos diarios que el local ya tenía. No hizo falta ninguna aplicación, porque el cliente que ya conocía el local solo necesitaba un enlace claro en el ticket, en la carta y en el mensaje de confirmación.
La clínica que perdía sesenta horas al mes al teléfono
Aquí el dato que lo decidió todo fue el tiempo de recepción: unas 900 citas al mes y alrededor de cuatro minutos de llamada por cada una, lo que se acerca a 60 horas mensuales dedicadas exclusivamente a coger el teléfono y apuntar. Llevar solo el 60 por ciento de esas reservas a internet devuelve unas 36 horas al mes, que son aproximadamente un día de trabajo por semana devuelto al mostrador. La solución fue añadir la reserva de citas en línea a la web que ya tenían, y la aplicación quedó aparcada hasta que el circuito de recetas repetidas la justificara por sí mismo.
La empresa de servicios con cuarenta furgonetas
Este es el caso en el que la aplicación era claramente lo correcto, y lo dijimos desde la primera reunión. Los técnicos rellenan partes de trabajo, hacen fotos y recogen firmas en sótanos, cuartos de máquinas y polígonos donde la cobertura no existe, así que el trabajo tenía que funcionar sin señal y sincronizarse al volver. Lo interesante es lo que decidimos dejar fuera: todo lo que ve el cliente final, presupuestos, seguimiento del aviso y facturas, se quedó en la web, porque un cliente que llama al fontanero dos veces al año jamás se habría instalado nada. Puede ver cómo resolvemos este tipo de encargos en nuestros casos de éxito.
Cómo decidirlo esta semana y qué traernos
El orden que recomendamos lo decimos en voz alta y sin matices: construya la web, mida durante tres meses y decida entonces la cuestión de la aplicación con números en lugar de con una intuición. Casi nunca perderá nada esperando ese trimestre, y en cambio se ahorrará mucho si los datos le dan una respuesta distinta de la que esperaba.
Antes de cualquier reunión, con nosotros o con quien sea, reúna estos cuatro números, que están todos a su alcance y valen más que un pliego de requisitos de treinta páginas:
- Qué porcentaje de sus visitantes entra desde el móvil, un dato que cualquier herramienta de analítica le da en un minuto.
- Cuántas veces al mes vuelve un cliente que ya le ha comprado una vez, porque esa es la pregunta uno disfrazada de dato real.
- Cuántas reservas, pedidos o llamadas gestiona su equipo a mano cada mes, y cuánto tiempo se va en ello.
- Qué comisión paga hoy a un portal, un intermediario o una agencia, expresada en dinero al año y no en porcentaje.
Lo que ocurre en una primera llamada con Linkysoft es exactamente esto: repasamos con usted las cinco preguntas, ponemos precio a las dos o tres opciones que tengan sentido y le decimos que no construya la aplicación cuando los números digan que no. Preferimos perder ese encargo antes que entregar un proyecto que se abandona en el segundo año, porque un proyecto pequeño terminado bien vale mucho más que uno grande a medio camino.
Un apunte final que ahorra bastante dinero: muy a menudo, lo que el cliente imaginaba que necesitaba una aplicación para conseguir, responder dudas al instante, encontrar un producto entre miles o guiar a alguien hasta la reserva, se resuelve con un asistente conversacional o un buscador inteligente dentro de la propia web. Es una fracción del presupuesto de una aplicación y se puede probar en semanas, así que conviene descartar esa vía antes de dar por buena la otra.
Si quiere una opinión directa sobre su caso concreto, tráiganos esos cuatro números y se la damos, incluida la versión en la que le decimos que se gaste menos. Puede empezar por nuestra página de contacto, o seguir leyendo el resto de la serie en el blog de Linkysoft, donde desmontamos las demás preguntas de presupuesto con la misma calculadora.
