Bugfender: La innovadora herramienta de desarrollo de software para la depuración de aplicaciones móviles

Bugfender es una herramienta que ayuda a los desarrolladores a depurar sus aplicaciones móviles recopilando los registros de los dispositivos móviles de sus usuarios. Empezó como una herramienta interna, pero Jordi y su cofundador vieron un gran potencial y decidieron convertirla en un negocio paralelo. Ahora tienen 165 clientes de pago, haciendo un MMR de +€9,100/mes. Jordi hace un poco de todo en la empresa, desde gestión de proyectos hasta desarrollo back-end e iOS, ventas, atención al cliente, creación de campañas de publicidad online y redacción de contenidos para su blog.

Bugfender es una herramienta que ayuda a los desarrolladores a depurar aplicaciones móviles recopilando registros de los dispositivos móviles de sus usuarios. Jordi y su cofundador vieron su enorme potencial y decidieron transformarla en una empresa paralela. Actualmente tienen 165 consumidores de pago, lo que supone un MMR de +9.100 euros al mes. Descubre cómo construyeron y desarrollaron Bugfender, así como los errores que cometieron.

¿Cuál es su trayectoria y en qué se centra actualmente?

Hola a todos. Me llamo Jordi Giménez. Estudié informática en Barcelona, lo que me llevó a trabajar en back-end web, front-end web, seguridad informática y otros campos. Mi camino me ha llevado últimamente al desarrollo iOS y Android. Tuve la suerte de cofundar dos empresas en Barcelona, Mobile Jazz y Bugfender.

Además de Mobile Jazz y Bugfender, llevamos a cabo experimentos como Localname, un servicio que da a tu estación de trabajo de desarrollo local una URL accesible por Internet, y DevCraft, un boletín para desarrolladores curiosos. Ambos están en fase de pruebas, y pueden o no convertirse en "algo" en el futuro.

Bugfender es una herramienta que ayuda a los desarrolladores a depurar sus aplicaciones móviles recopilando registros de los dispositivos móviles de sus usuarios desde cualquier lugar del mundo. Recopilamos los registros y los organizamos en una interfaz optimizada que permite filtrar y ver los datos por usuario, periodo de tiempo, fabricante del dispositivo móvil y criterios similares. Bugfender permite el acceso remoto a las capacidades de supervisión de los dispositivos de los usuarios.

Empezamos la empresa con solo tres empleados, pero ahora tenemos nueve. Bugfender está implantado actualmente en más de 9.000 aplicaciones y funciona en más de 46 millones de dispositivos. En cuatro años, pasamos de cero a $11.000 en ingresos recurrentes mensuales (MRR) sin inversión externa.

Soy responsable de diversas tareas en la empresa, como la gestión de proyectos, el desarrollo back-end e iOS, las ventas, la atención al cliente, la creación de campañas de publicidad en línea y la creación de contenidos para blogs. Cada día es un poco diferente.

Evidentemente, todo lo que hacemos está autofinanciado. Como propietarios, somos los únicos inversores; hemos invertido nuestro tiempo en lugar de una gran suma de dinero. Después de cuatro años, nuestro equipo se ha reducido a nueve miembros, algunos a tiempo parcial, y somos extremadamente frugales con nuestras finanzas. Por ejemplo, el objetivo de una campaña publicitaria es crear un producto por el que la gente esté dispuesta a pagar. Como muchos artículos son "gratuitos", es decir, no cuestan dinero, nuestros anuncios pueden confundir un poco a los consumidores potenciales. Los consumidores deben ser conscientes de que, incluso con los productos SaaS "gratuitos", siguen pagando de alguna manera, como por ejemplo al recibir publicidad y vender sus datos al mejor postor.

En cambio, nosotros buscamos clientes honrados que valoren nuestras ofertas y estén dispuestos a pagar por ellas. Afortunadamente, hay suficientes de estas personas para que pronto alcancemos el punto de equilibrio. Podríamos haber alcanzado ya el punto de equilibrio si hubiéramos dejado de invertir en la empresa, pero hemos optado por seguir invirtiendo por encima de nuestros ingresos, a pesar de que esto tiene un impacto menor en nuestras finanzas por el momento. Aquí puedes ver nuestros números en tiempo real, ya que son muy transparentes.

Además, la empresa es completamente remota. Yo estoy en Barcelona, pero mi equipo está disperso por toda Europa. De vez en cuando organizamos retiros o "workations" mientras trabajamos a distancia. Desde el principio, nos dimos cuenta de que las reuniones cara a cara son esenciales para la productividad y el desarrollo del equipo. Además, es muy divertido.

‍

¿Cuál es su historia y cómo desarrolló este concepto?

Yo mismo empecé a desarrollar aplicaciones móviles en 2011. En aquel momento estaba desarrollando mi primera aplicación móvil para Android: una aplicación para controlar el saldo de mi tarjeta SIM de prepago. Fue un experimento que realicé para entender mejor Android. Me fastidiaba que mi proveedor de telefonía móvil no tuviera una aplicación y que tuviera que consultar constantemente su página web para asegurarme de que mi saldo no caducaba.

Por lo tanto, desarrollé una aplicación que utilizaba "web scraping" para recuperar el saldo de mi cuenta del sitio web. El web scraping utiliza una aplicación para iniciar sesión en un navegador web como un usuario real, seleccionar los botones adecuados para acceder a la página que contiene la información deseada y, a continuación, extraer o "raspar" la información para su uso.

A mí me funcionó a la perfección. Como el operador carecía de aplicación, decidí hacerla pública por si podía ser beneficiosa para alguien más. Resultó ser cierto. En pocos meses, atrajo a más de 20.000 usuarios, una parte significativa de los abonados del operador en aquel momento.

Sin embargo, el problema del rastreo web es que, a diferencia de los humanos, las aplicaciones pueden confundirse por alteraciones rutinarias en la redacción o la estructura de la información mostrada. Por ejemplo, en aquel momento mi aplicación era utilizada tanto por usuarios de prepago como de contrato, por lo que el sitio web aparecía ligeramente diferente para cada tipo de usuario en función del producto, lo suficiente como para dañar mi aplicación.

Para solucionar este problema, decidí crear un pequeño servicio web al que mi aplicación pudiera enviar datos si el contenido no se ajustaba a las expectativas. De este modo, podía ver lo que veía mi aplicación y corregir posibles errores. Esta fue la versión inicial de Bugfender. Pero en aquel momento no tenía ningún efecto sobre mí; era simplemente una solución que descubrí para un problema concreto al que me enfrentaba en aquel momento.

Poco después conocí a Stefan a través de un contrato de consultoría de aplicaciones móviles. Juntos fundamos la consultora de software Mobile Jazz. En Mobile Jazz, ayudamos a nuestros clientes a desarrollar sus ideas y luego realizamos todo el trabajo de especificación y diseño necesario para transformar esas ideas en aplicaciones web y móviles.

En 2015, el concepto Bugfender renació en el contexto de Mobile Jazz. Un colega, Aleix, se encontró con el mismo problema mientras trabajaba en el encargo de un cliente. Nuestra aplicación móvil estaba interactuando con un servidor fuera de nuestro control, y uno de nuestros evaluadores beta se quejó de que la aplicación no le funcionaba. Sin embargo, ¡a nosotros sí nos funcionaba! Como ni su teléfono ni el servidor eran visibles, estábamos completamente a oscuras. De nuevo, Aleix ideó la misma solución: desarrollar una herramienta para enviar todos los datos a un servidor. Aleix estaba tan entusiasmado con la idea que se apresuró a montarla durante el fin de semana y nos la presentó orgulloso el lunes.

‍

Me quedé atónito. Enfrentados al mismo problema, ambos habíamos llegado a la misma resolución. Esto me demostraba que íbamos por buen camino. ¡Esto tenía que ser algo!

‍

¿Cómo construyó Bugfender?

Inmediatamente después de la demostración de Aleix, hablé con él. Recuerdo que estaba extasiado porque yo tenía el mismo problema y había escrito exactamente la misma solución cuatro años antes, y quería colaborar con él en ella. Además, Stefan la apreciaba, así que los tres decidimos mejorarla y utilizarla como herramienta interna para Mobile Jazz.

En aquel momento no tenía nombre porque era sólo un experimento. Lo llamábamos "registrador remoto" porque transmite los registros a distancia.

Cuando Aleix creó la primera iteración del software, el código introducido en las aplicaciones móviles consistía en una única clase que enviaba registros al servidor. No se trataba en absoluto de un kit de desarrollo de software (SDK) legítimo, sino simplemente de un trozo de código que copiábamos y pegábamos en el código fuente de las aplicaciones individuales. El servidor era totalmente incompetente; simplemente almacenaba todos los datos que se le enviaban. En total, probablemente no había más de 200 líneas de código.

La versión inicial se construyó con Go como experimento (¡un experimento dentro de un experimento! ), que almacenaba los registros en una base de datos MySQL.

Sin embargo, aunque rudimentaria, ¡ya nos estaba ayudando! Ahora, si un consumidor tenía un problema, podíamos crear una versión especial de la aplicación que incluyera esta función de "registro remoto". El sistema nos enviaría entonces los registros para que pudiéramos ver lo que estaba ocurriendo. ¡Hurra!

Pronto nos dimos cuenta de que sería preferible incluir el código del "registrador remoto" en todas las compilaciones de la aplicación y activar/desactivar el registro de forma remota cuando detectáramos un problema en el dispositivo. Esa fue nuestra evolución inicial.

Después, siguió evolucionando. Al principio, la utilidad se concibió como un medio para ofrecer un mejor servicio a los clientes consultores de Mobile Jazz, pero pronto nos dimos cuenta de que otros desarrolladores de aplicaciones se encontraban con el mismo impedimento. En el desarrollo móvil, siempre existe este problema: cuando un usuario se encuentra con un problema, es casi imposible reproducirlo, a diferencia del desarrollo web y de escritorio. En estas tecnologías, siempre es posible verificar los registros del servidor o del ordenador de sobremesa. Al contrario que en móvil.

A veces, las aplicaciones móviles funcionan sin servidor, pueden interactuar con servidores que no están bajo tu control o pueden interactuar con dispositivos con Bluetooth o Wifi, por lo que no puedes predecir lo que está ocurriendo. Otro problema es la llamada "fragmentación de dispositivos"; hay tantos tipos distintos de teléfonos móviles en el mercado que necesitarías miles de ellos para probar adecuadamente tu aplicación. Incluso con la misma configuración y las mismas condiciones, algo que funciona para ti puede no funcionar para otra persona con un dispositivo móvil diferente.

Tras cinco meses de uso interno de Bugfender, se hizo evidente que nos enfrentábamos a un problema universal por cuya solución otras empresas podrían estar dispuestas a pagar. Por tanto, decidimos crear Bugfender como producto. Creamos un sitio web e incluimos un formulario de "solicitud de invitación". Al principio, no había cuotas y teníamos que acceder manualmente a la base de datos y crear las cuentas. Incluso faltaba un formulario formal de inscripción. Debido al reducido número de personas que solicitaban acceso, no fue una tarea tediosa. Intentamos promocionar nuestra solicitud en foros de desarrolladores y en Twitter, pero recibimos pocas respuestas.

Sin embargo, interactuar con consumidores reales fue beneficioso. Empezamos a recibir comentarios objetivos, críticas y peticiones de funciones.

Tardamos aproximadamente cuatro meses en añadir el proceso de pago porque estábamos ansiosos por seguir incorporando comentarios y mejorando nuestra herramienta antes de cobrar. No pensamos mucho en el precio porque nuestro objetivo inicial era determinar si las personas estaban dispuestas a pagar algo. Por lo tanto, visitamos el sitio web de un competidor y establecimos nuestros precios de forma similar.

Una vez puesto en marcha el sistema de pago, tardamos otros seis meses en conseguir nuestro primer cliente de pago. Fueron tiempos difíciles, pero estábamos llenos de entusiasmo. Cuando llegó el momento, lo celebramos. Un usuario de pago indicaba que no éramos tontos del todo y que estábamos creando algo que alguien quería, aunque sólo fueran 19 euros al mes.

Una vez que se empieza a cobrar, la situación se vuelve más grave. ¿Deberíamos constituirnos como empresa? La gente empieza a preguntarnos: "¿Cuál es nuestra política de privacidad?", y tenemos que dar una respuesta. ¿Nuestros términos y condiciones? ¿Codificamos su información? (Obviamente, lo hacemos).

Además, tuvimos numerosas dudas por el camino: ¿habíamos identificado el "producto-mercado" óptimo? Teníamos muy claro que el dinero no aparecería por arte de magia. Se trataba de un artículo especializado. Bugfender resolvía una pequeña molestia para los desarrolladores, pero aún no estábamos seguros de que resolviera un problema importante. ¿Podríamos convencer a un número suficiente de personas para que introdujeran sus tarjetas de crédito?

Incorporar un negocio, incorporar métricas de software para limitar la funcionalidad en función del plan, e integrar un sistema de pago y facturación... (¡¡¡OMG si eres una persona influyente en la Unión Europea y estás leyendo esto, calcular el IVA correcto para una factura es ridículamente complicado!!!). ¿Mereció la pena todo este esfuerzo, quizás sin recibir nada a cambio... nunca?

Experimentamos algunos altibajos durante el proceso de lanzamiento y los meses posteriores. Nuestro primer cliente de pago fue motivo de celebración. Aunque era una suma pequeña, sirvió de validación. Cuando solicitamos una subvención a la Unión Europea y fuimos elegidos entre miles de solicitantes, fue un momento adicional de emoción. Nos concedieron 100.000 euros para el desarrollo de nuestro producto, así que ya no teníamos que desarrollarlo con nuestro propio dinero. Recuerdo haber hablado de abandonar el barco con los demás creadores unas semanas antes.

También nos animó a continuar el recibir comentarios directos de nuestros usuarios a través de mensajes. El foro tuvo un impacto significativo en la adopción porque nos permitió comunicarnos con los usuarios potenciales y resolver sus dudas. Pudimos ayudar a nuestros consumidores actuales, lo que aumentó la retención. También fue una ocasión inestimable para aprender de primera mano de quienes utilizaban el producto. Esto nos permitió crear un sitio web que responde a las verdaderas preguntas de los usuarios.

¿Qué estrategias de marketing empleó para ampliar su negocio?

Nuestro crecimiento ha sido muy orgánico desde el principio. Confiábamos en nuestra capacidad para crear el producto, pero no teníamos experiencia en marketing. Lo más difícil ha sido comunicar nuestro producto a las personas adecuadas.

Tras recibir la subvención de la UE, nuestro mentor (¡hola, Agustín!) insistió en que nos dedicáramos al marketing de contenidos. ¿Qué demonios era eso? Teníamos conocimientos limitados. Nos asignó una tarea: realizar un estudio de palabras clave, para el que nos dio instrucciones. Entonces, seleccionamos las 20 palabras clave que creíamos que tendrían mayor impacto en nuestro desarrollo y empezamos a trabajar en ellas. Al cabo de seis meses, nuestro objetivo era aparecer en la primera página de Google con al menos diez de esas palabras clave.

Esto es más fácil de decir que de hacer; ¡mejorar el SEO requiere un esfuerzo considerable! Los tres miembros fundadores de Bugfender eran ingenieros. En aquel momento, ése era todo nuestro equipo. Los ingenieros no son especialmente aficionados a la escritura, pero este proyecto requería escribir mucho. Por lo tanto, era un doble reto para el ingeniero. Pero perseveramos y lo conseguimos. No sólo aparecimos en la primera página en la mayoría de las búsquedas de palabras clave, sino que también ocupamos el primer lugar en algunas. Esto ayudó mucho a nuestro desarrollo porque, por primera vez, recibimos una cantidad sustancial de tráfico orgánico.

También intentamos otros métodos que no tuvieron éxito. Otros nos aconsejaron utilizar AdWords, anuncios en Facebook, anuncios en LinkedIn y anuncios en Twitter. Probamos cada una de estas opciones porque todas tenían lógica para nosotros. Invertimos una cantidad considerable de tiempo y dinero en establecerlo todo, pagando factura tras factura, probando e iterando. Aunque funcionó para atraer más visitantes, seguimos gastando bastante más de lo que ganábamos en nuevos usuarios y, en última instancia, en ventas. Yo diría que valió la pena intentarlo, pero aconsejaría a las empresas que empiezan que prueben otras cosas primero y que sean muy frugales con sus presupuestos de publicidad. Cuando se utilizan anuncios, se compite con grandes empresas con enormes presupuestos de marketing. Yo reservaría esta estrategia para las empresas respaldadas por capital riesgo con bajas barreras de adquisición por parte del consumidor, como los productos complementarios.

Nuestra experiencia con el retargeting de Facebook ha sido positiva. A las personas que han visitado nuestro sitio web y han expresado interés por Bugfender se les muestran anuncios. Ha sido una estrategia mucho más acertada, ya que nos dirigimos a particulares y no a grandes organizaciones, que tienen muchas más probabilidades de convertirse en clientes.

Anticipamos que nuestros consumidores estarían tan entusiasmados con el uso de Bugfender que correrían la voz. Creamos todo un sistema de recomendación con códigos de descuento e invitaciones, similar a la conocida estrategia de Dropbox. Nos equivocamos; las personas tenían cosas más importantes que hacer. Disfrutaban utilizando nuestro producto, pero convencer a sus compañeros para que lo adoptaran era otra cosa.

También intentamos participar en las redes sociales, como Twitter, Facebook y LinkedIn, pero las encontramos saturadas de mensajes de marketing. Tener una interacción significativa lleva mucho tiempo y, al final, todo el mundo emplea las mismas estrategias, lo que dificulta enormemente diferenciarse de la multitud. Recientemente hemos descubierto que ser más activos en Twitter nos ha beneficiado, probablemente porque los desarrolladores se congregan más allí, así que estamos aumentando nuestros esfuerzos allí mientras disminuimos nuestra actividad en otras redes.

También utilizamos pruebas A/B para mejorar el contenido de nuestro sitio web. Aunque en principio suene bien, se necesitan decenas de miles de visitantes a su sitio web para obtener resultados significativos. Y a menudo estas pruebas no son concluyentes porque hay poca diferencia entre los elementos que se prueban, o porque el efecto sobre su tasa de conversión es tan insignificante que no importa, por lo que hemos comprobado que tienen una utilidad limitada en nuestro caso.

Hasta ahora, hemos determinado que el marketing de contenidos es nuestro hobby, y seguimos trabajando en ello. Pero no hemos dejado de intentar cosas nuevas, y seguiremos haciéndolo; probablemente nunca pararemos, dado que los tiempos y las empresas cambian. Quizá algunas de las cosas que hemos intentado en el pasado tengan éxito en el futuro.

‍

¿Cuáles fueron los mayores obstáculos a los que se enfrentó y cómo los superó?

Ya he descrito algunos de los altibajos emocionales. La escasez de recursos financieros ha sido el mayor obstáculo hasta la fecha. Todo se gestiona con nuestro propio tiempo y fondos, lo que se ha hecho cada vez más difícil. En circunstancias difíciles, uno puede empezar a cuestionarse si merece la pena continuar. La inversión está dando escasos frutos, ¡pero funciona!

Actualmente estamos en una situación casi rentable, lo que nos permite cubrir nuestros gastos pero no pagarnos un sueldo. Aún así, no necesitamos seguir aportando dinero, lo cual es una ventaja, pero debemos trabajar gratis. Espero que alcancemos lo antes posible la llamada "rentabilidad ramen", momento en el que cobraremos algo, aunque sea una pequeña cantidad, que quizá no suponga una gran diferencia, pero que sin duda nos ayudará a levantar el ánimo.

Actualmente hemos superado esta limitación dividiendo nuestro tiempo entre Bugfender y la consultoría de Mobile Jazz. No es óptimo, pero funciona a pesar de la extrema dificultad.

¿Cuáles son sus desventajas más importantes?

Es difícil hablar de desventajas por dos motivos: primero, no queremos verlas, y segundo, muchas ventajas y desventajas son, en mi opinión, dos aspectos de la misma moneda. Por lo tanto, te definen pero no determinan tu destino. Me explico:

Se podría argumentar que el bootstrapping es una vulnerabilidad, por ejemplo. Sin embargo, creo que será una ventaja si conseguimos que la empresa sea rentable, lo que es muy probable. La falta de recursos abundantes nos ha hecho sabios (o nos ha ayudado a "mantenernos hambrientos", como diría Steve Jobs), y somos capaces de hacer funcionar nuestro negocio con unos ingresos mensuales reducidos. Por lo tanto, el bootstrapping nos ha hecho parsimoniosos, lo cual es bueno. Por desgracia, es demasiado habitual que las empresas fracasen porque han agotado sus recursos.

Además, Bugfender es un producto de pago. Hay una versión gratuita disponible para experimentar, pero lo "bueno" está reservado para los clientes de pago. De nuevo, esto es una vulnerabilidad, porque si Google/Facebook/Twitter lanzan mañana una versión gratuita de un producto similar a Bugfender, podríamos tener dificultades para competir. De nuevo, la desventaja es evidente, pero ¿cuál es el beneficio? Si no pagas por algo, no eres el consumidor; eres el producto que se vende. Sabemos muy bien quiénes son nuestros consumidores y protegemos su intimidad. No hay ningún producto gratuito que pueda ofrecer esto.

También he dicho que nuestro mercado objetivo son los desarrolladores de móviles. Esto implica fundamentalmente que operamos en un ecosistema gobernado por Apple y Google. Sin duda se puede ganar mucho dinero, pero el riesgo de depender de estas dos empresas no es insignificante. En mi opinión, esto es cierto para cualquiera que trabaje en una aplicación o un producto para aplicaciones. La única solución es ser consciente de este riesgo y diversificar tan pronto como sea posible.

‍

En el proceso de construcción y ampliación de Bugfender, ¿cuáles fueron los peores errores que cometió?

Personalmente, soy consciente de que soy demasiado pesimista. Dado que podría dañar la moral del equipo, debo tener cuidado con cómo expreso las cosas y cómo les comunico mis emociones. Afortunadamente, me he asociado con las personas adecuadas y nos apoyamos mutuamente cuando las cosas se tuercen. Hasta ahora ha sido un éxito.

He mencionado que todo el equipo de Bugfender trabaja también en Mobile Jazz por consideraciones principalmente económicas. Posiblemente podríamos haber tomado antes la decisión de contratar a un empleado externo de Bugfender a tiempo completo. Creo que la multitarea nos ha hecho desatender algunas oportunidades excelentes.

Además, creo que todavía no hemos experimentado lo suficiente con los precios como empresa. Nuestros precios se basan en ciertas suposiciones, pero no hemos realizado pruebas exhaustivas. Por ejemplo, actualmente ofrecemos un plan gratuito que creemos que anima a las personas a probar Bugfender sin preocupaciones. Sin embargo, ¿cómo funcionaría sustituir el plan gratuito por una versión de prueba? No lo sabemos.

En el frente tecnológico, también hemos cometido errores. Trabajar en Go parecía inicialmente atractivo porque estábamos ansiosos por aprender nuevas tecnologías, pero Go era inmaduro en aquel momento, y hemos pagado el precio. Además, seguimos luchando por encontrar desarrolladores cualificados.

La selección de bibliotecas fue fuente de problemas. Elegimos martini como framework web, pero su rendimiento era tan inadecuado que incluso su autor se pasó a un nuevo proyecto llamado gin. La migración de Martini a la biblioteca HTTP nativa ha supuesto una mejora de 10 veces en el rendimiento, lo que nos ha ahorrado literalmente decenas de miles de dólares al mes. Accedíamos a la base de datos utilizando gorm (versión 1). Además, gorm se reescribió sustancialmente en los meses posteriores, lo que dio lugar a una API incompatible con la versión que utilizamos; esto requiere principalmente reescribir nuestro código y realizar una migración de datos exhaustiva... probablemente abandonaremos gorm en favor de sqlx, una biblioteca ampliamente utilizada que nos ofrece un mayor control sobre el rendimiento. Supongo que esto es un reflejo de la evolución del lenguaje a medida que madura la comunidad de desarrollo.

Hemos recopilado una lista de pros y contras en una entrada del blog sobre Go y la selección de bibliotecas, con la esperanza de que ayude a otros a tomar mejores decisiones en el futuro.

Además, nos vimos obligados a evolucionar el primitivo sistema basado en MySQL. Las bases de datos relacionales son inadecuadas para tareas de escritura intensiva como el almacenamiento de registros. Redis se utiliza para almacenar en caché los datos a los que se accede con más frecuencia, mientras que Kafka y Elasticsearch se emplean para almacenar registros.

Si tuviera la oportunidad de hacer las cosas de otra manera, ¿qué haría diferente?

Yo contrataría inmediatamente a un profesional del marketing. Subestimamos enormemente la cantidad de esfuerzo que requiere el marketing. Creíamos que unos cuantos anuncios y unas cuantas entradas en el blog bastarían para que la gente nos conociera. Si pudiera volver atrás en el tiempo, buscaría a alguien que trabajara en marketing en nuestro sector y le contrataría en cuanto el dinero me lo permitiera.

Pasado un tiempo, todo se vuelve más nítido. Obviamente, si hubiéramos sabido que colocar anuncios era ineficaz, habríamos dedicado mucho menos tiempo y dinero a intentar ponerlos en práctica. El proceso de identificar la estrategia de marketing óptima ha llevado mucho tiempo, pero es necesario.

Ojalá hubiera dedicado más tiempo a conversar con posibles clientes. Después de tres años en el negocio, sigo encontrándome con personas que no "entienden" lo que hacemos. Esto no implica que sean estúpidos; más bien indica que yo no puedo articular adecuadamente la situación (lo que me convierte en el idiota). Intento comunicarme ampliamente con los clientes y consumidores potenciales, pero creo que más tiempo habría dado mejores resultados.

Antes de lanzar Bugfender, también probamos un producto de la competencia. Se titulaba "PlayThis" y era una lista de reproducción colaborativa para seleccionar música de celebración. Pretendíamos que fuera gratuito o barato para actos privados (como en casa) y venderlo a establecimientos. Pasamos varios meses desarrollando el producto antes de lanzar una versión a la tienda de aplicaciones. ¿Sabe quién frecuentaba los establecimientos en aquella época? Nadie. ¿Sabes cuántas copias del software vendimos? Ninguna, nunca. Esto nos enseñó una valiosa lección: debemos comunicarnos con los consumidores antes de construir nada.

Como soy consciente de la pronunciada curva de aprendizaje y de la prevalencia de este error entre los emprendedores, quiero insistir: no escribas ni una sola línea de código hasta que tengas un cliente de pago.

Mejor aún es si consigues que alguien pague por adelantado (o al menos se comprometa a comprar). Además de financiar tu proyecto, así te asegurarás de que contiene los componentes necesarios y ofrece una solución (al menos a una persona).

Y lo contrario también es cierto: no importa lo impresionante que sea su tecnología o su idea. Si nadie la conoce, nadie la comprará. Una vez que hables con tus primeros clientes potenciales, te darás cuenta de que pueden necesitar algo totalmente distinto de lo que tenías en mente, o de que lo que creías que era una oportunidad de mercado sin explotar, a nadie le interesa.

En cuanto a la tecnología, yo habría empezado con una plataforma tecnológica conocida. No habría sido tan agradable, pero habría acelerado la empresa y nos habría ahorrado dinero. Debido al bajo rendimiento del software, hace tiempo que tenemos que actualizar nuestra infraestructura, lo que nos cuesta miles de dólares al mes. Además, tenemos una carga peculiar, ya que generamos terabytes de registros cada mes y debemos hacerlos fácilmente accesibles a los usuarios que deseen revisarlos. Más aún si no estás familiarizado o no tienes experiencia con la pila tecnológica, encontrar el equilibrio entre estas optimizaciones es difícil.

‍

Además de los errores, ¿qué otros recursos de aprendizaje recomendaría a los aspirantes a empresarios?

No todo el mundo disfruta con los mismos medios, así que voy a recomendar algunos de mis favoritos. Como me gusta leer, me gustaría recomendar "La prueba de la madre". Es un libro breve y dulce que me benefició enormemente en el departamento de "hablar con los clientes". Creo que todo empresario debería leerlo antes de emprender cualquier empresa.

Además, el libro Start Small, Stay Small, el libro The Lean Startup y el blog Signal vs. Noise hablan del bootstrapping, es decir, de construir un proyecto con tu propio tiempo y dinero y sin ayuda de inversores o con una ayuda mínima. Ahora bien, no todos los proyectos pueden construirse de esta manera, pero mucha gente desconoce esta alternativa a la financiación con capital riesgo, por lo que yo recomendaría aprender más sobre ella y determinar qué método es el más adecuado para tu idea.

Aprecio el podcast Smart Passive Income por sus conceptos, la mayoría de los cuales son bootstrapped. Este formato me da mucha vitalidad. El podcast Rework es una magnífica recopilación de historias empresariales de diversos emprendedores. Frecuento los foros de Indie Hackers y Hacker News.

También tuve que aprender mucho sobre marketing, ya que entré en el mercado laboral sin saber nada al respecto. Escucho habitualmente el podcast, el blog y el boletín de Neil Patel, y adoré su libro Traction: A Startup's Guide to Acquiring Customers.

Más información

Debería visitar la Sitio web de Bugfender. Para saber más sobre nuestro viaje, consulte Tres años de Bugfender: 9,5 millones de usuariosuna retrospectiva que escribimos con motivo de nuestro tercer aniversario, y Cuatro lecciones aprendidas del arranque de productosuna colección de reflexiones sobre nuestras lecciones.

Mi cofundador Stefan Klumpp también apareció en una entrevista con Indie Hackers hace un año, donde puedes saber más sobre nuestras primeras fases, financiación y hoja de ruta.

Si desea ponerse en contacto conmigo, mis cuentas de Twitter son @bugfenderapp y @gimix3.

La foto principal es de bugfender.com

Recopilamos estudios de casos empresariales únicos de todo Internet, para inspirarle con una amplia gama de ideas de negocio. Este caso práctico fue supervisado por nuestro equipo y sin duda captó nuestro interés. Puedes encontrar otras historias de negocios inspiradoras aquí.