Cada aplicaci\u00f3n que lanzamos se enfrenta a la misma pregunta inicial: \u00bfc\u00f3mo genera ingresos? No hay una respuesta universal, pero s\u00ed un marco de trabajo que utilizamos y que nos ha evitado muchos errores iniciales.<\/p>\n
El marco es f\u00e1cil de explicar. Partimos de lo que nos cuesta mantener la aplicaci\u00f3n en funcionamiento y de lo que realmente obtiene la persona que la utiliza, y buscamos el modelo en el que ambos aspectos coincidan. No el modelo que generar\u00eda m\u00e1s beneficios en una hoja de c\u00e1lculo, ni el que utilice por casualidad un competidor. Sino aquel que refleje con honestidad la naturaleza del trabajo.<\/p>\n
Somos un peque\u00f1o estudio autofinanciado, as\u00ed que esto no es algo abstracto. No contamos con fondos de inversores para financiar un modelo que no se autofinancie, ni con un equipo de crecimiento que pueda disimular uno que moleste a la gente. Sea cual sea nuestra elecci\u00f3n, tiene que funcionar por s\u00ed misma.<\/p>\n
En el caso de las aplicaciones cuyo valor se obtiene en el momento de su uso y que no requieren una infraestructura continua por nuestra parte \u2014como convertidores de im\u00e1genes, calculadoras o utilidades sencillas\u2014, cobramos una sola vez. El usuario paga, se queda con la aplicaci\u00f3n y nosotros seguimos adelante.<\/p>\n
\u201cDecir \u201dpasar p\u00e1gina\u00bb es un poco exagerado. Una aplicaci\u00f3n que solo se instala una vez sigue necesitando actualizaciones cuando cambia el sistema operativo, y esas actualizaciones no son gratis. Lo que hemos aprendido es a fijar el precio teniendo eso en cuenta, en lugar de fijarlo en la cifra m\u00e1s baja que acepte una tienda. Una peque\u00f1a utilidad de escritorio que realiza una \u00fanica tarea en tu propio ordenador, sin que nada por nuestra parte genere un gasto mensual, encaja perfectamente en este modelo.<\/p>\n
En el caso de las aplicaciones que nos suponen un coste real continuo (servidores de sincronizaci\u00f3n, inferencia de IA, actualizaciones peri\u00f3dicas de contenido), ofrecemos una suscripci\u00f3n. Intentamos fijar el precio m\u00e1s o menos en lo que necesitar\u00edamos que pagara el usuario medio para cubrir gastos, y no en lo m\u00e1ximo que podr\u00edamos cobrar.<\/p>\n
La prueba que aplicamos consiste en ver si podemos explicar, en una sola frase, a qu\u00e9 se destina el dinero que se paga cada mes. Si la respuesta es \u201cun servidor que mantiene tus datos sincronizados entre dispositivos\u201d o \u201cprevisiones que tenemos que recabar y procesar cada d\u00eda\u201d, la suscripci\u00f3n est\u00e1 justificada. Si la respuesta es \u201cporque los ingresos recurrentes quedan mejor\u201d, no lo es. Una aplicaci\u00f3n que necesita datos actualizados para seguir siendo \u00fatil es precisamente el tipo de caso en el que nos planteamos seriamente la posibilidad de una suscripci\u00f3n.<\/p>\n
Es poco habitual. Solo lo hacemos cuando la aplicaci\u00f3n es tan informal que incluso un peque\u00f1o muro de pago impedir\u00eda que los usuarios la descubrieran, y cuando hemos encontrado un socio publicitario que no realiza un seguimiento de los usuarios entre aplicaciones. Cada a\u00f1o resulta m\u00e1s dif\u00edcil cumplir ambas condiciones.<\/p>\n
No descartamos la publicidad. Es una forma leg\u00edtima de financiar software por el que la gente no pagar\u00eda de otro modo, y para algunas aplicaciones puede resultar la decisi\u00f3n m\u00e1s acertada. Lo que nos preocupa es la ubicaci\u00f3n y los socios: un anuncio que interrumpe precisamente aquello para lo que sirve la aplicaci\u00f3n supone un coste que paga el usuario, aunque nunca aparezca en un recibo.<\/p>\n
El modelo intermedio: una aplicaci\u00f3n gratuita que resulta realmente \u00fatil por s\u00ed sola, con una versi\u00f3n de pago para quienes quieran m\u00e1s. Este es el que m\u00e1s nos cuesta acertar. Si el umbral es demasiado bajo, la versi\u00f3n gratuita parece una demo. Si es demasiado alto, nadie se pasa a la versi\u00f3n de pago y la aplicaci\u00f3n no puede mantenerse. Cuando la utilizamos, la regla es que la versi\u00f3n gratuita tiene que ser algo que recomendar\u00edamos encantados por s\u00ed sola.<\/p>\n
En cuanto a las herramientas, queremos que existan en cualquier caso. Algunas de nuestras aplicaciones m\u00e1s peque\u00f1as entran en esta categor\u00eda. Se financian gracias a las de pago.<\/p>\n
Nuestro primer instinto fue fijar el precio al final, una vez desarrollada la aplicaci\u00f3n. Eso fue un error. El precio da forma al producto: una aplicaci\u00f3n de suscripci\u00f3n necesita un motivo para que el usuario vuelva; una aplicaci\u00f3n de uso \u00fanico debe estar completa desde el primer d\u00eda; y una aplicaci\u00f3n gratuita debe tener un coste de funcionamiento bajo. Ahora elegimos el modelo antes incluso de dise\u00f1ar la primera pantalla y lo revisamos con franqueza si la aplicaci\u00f3n resulta ser algo diferente de lo que hab\u00edamos planeado.<\/p>\n
Ninguna de estas opciones es definitiva. Una aplicaci\u00f3n puede cambiar de modelo a medida que crece y var\u00edan sus costes; y cuando eso ocurra, lo diremos claramente y explicaremos por qu\u00e9.<\/p>","protected":false},"excerpt":{"rendered":"
Gratis, freemium, pago \u00fanico, suscripci\u00f3n\u2026 qu\u00e9 elegimos realmente y c\u00f3mo lo hacemos.<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-577","post","type-post","status-publish","format-standard","hentry","category-journal"],"yoast_head":"\n