Wrapper as a service

Se conoce como wrapper –o envoltorio– a un conjunto de utilidades que envuelven a un servicio que trabaja a más bajo nivel. Con el auge de las APIs de OpenAI, decenas de negocios son simplemente –o no tan simplemente– un wrapper alrededor de sus servicios.

Pero no podemos limitar el alcance de los wrappers únicamente a los productos de IA. Render es un wrapper alrededor de AWS. Lemonsqueezy es un wrapper alrededor de Stripe. Hay decenas y decenas de negocios que se han construido de esta forma. Esta forma de crear producto tiene sus ventajas y sus inconvenientes. Hablemos sobre ello.

Cómo de grueso es nuestro envoltorio

Al final todos los sistemas acaban envolviendo a otros sistemas de propósito más general. Lo primero que tenemos que analizar cuánto mejoramos al sistema original para nuestro caso de uso. Lógicamente es muy difícil crear un sistema de pago electrónico mejor que Stripe. Pero es posible adaptarlo para que nuestro sistema sea mucho más efectivo para un conjunto determinado de clientes. Hay dos puntos clave:

• Elegir bien a qué clientes queremos servir: cómo de numeroso es, cuál es su poder adquisitivo o cómo de capacitados estamos para acceder a ellos. En un principio deberíamos enfocarnos en un grupo pequeño pero que pueda extenderse fácilmente a otro más numeroso.
• Cuál es la diferenciación que vamos a proporcionar: qué hace que tu producto sea diferente para el público que has elegido en el punto anterior. Lógicamente no vas a hacer un modelo mejor que los de OpenAI pero igual proporcionas una serie de características que simplifiquen la aplicación de los modelos a una audiencia determinada.

Una vez has elegido estos dos puntos, tienes que construir el wrapper alrededor del producto original. Cuanto más acerques la funcionalidad que proporcionas hacia las necesidades concretas de tu público objetivo, más fácil será vendérselo a tus clientes.

Si ordenamos las soluciones que podemos ofrecer a un cliente de más abstracto a más concreto veremos que, según vayamos haciéndonos más concretos, se reducirá el tamaño de nuestro mercado pero podremos ser más caros. Podemos comparar una empresa de hosting generalista, como puede ser AWS, con una más centrada en el desarrollador, como puede ser Render.

Render está mucho más centrado en los desarrolladores y eso le permite ofrecer algunas funcionalidades que lo diferencian de AWS. Por ejemplo, bases de datos gestionadas o despliegues con sin ningún tipo de downtime. ¿Podríamos construir esas funcionalidades en AWS? Desde luego, invirtiendo tiempo de un buen técnico se puede tener algo equivalente. ¿Merece la pena? Pues dependerá de cuánto gastemos en Render, pero por lo general no.

Cuanto más concreta sea nuestra solución, más alejados estaremos del sistema original, por lo que será más difícil copiarnos y podremos cobrar más por el servicio. Cuanto más de bajo nivel sea nuestro proveedor de servicio, más lejos estará tu producto del proveedor y menos riesgo tendrás. No es lo mismo ser un wrapper de AWS, más abstracto y más fácil de replicar en otros entornos, que serlo de OpenAI, de momento mucho más concreto.

Ventajas y desventajas de estos modelos

• Podrás crear productos muy rápido: delegar el core tecnológico en otra empresa hará que el tiempo que tardas en poner el producto en el mercado sea muy rápido.
• Otros podrán tu producto igual de rápido: es difícil crear moats tecnológicos siguiendo estas metodologías. Puedes tratar de crear otros: tener muy buena UX o crear una marca serían dos de las opciones.
• Dependerás de un tercero y el riesgo de plataforma siempre está ahí: si todo tu producto depende de otra empresa, siempre existirá un riesgo de que esa empresa cambie sus condiciones y te funda. Muchísimos videojuegos que son un wrapper alrededor de Unity –un motor de desarrollo– han visto cómo sus condiciones de uso cambiaban de un día para otro. Han pasado de pagar una parte de su facturación a pagar por el número de instalaciones y esto hace inviables varios modelos de negocio.
• Si la plataforma sobre la que estás construyendo está en plena expansión, podrás aprovechar esa inercia para crecer.
• No solo existe el problema de los cambios en las condiciones, también existe el problema de que la plataforma incluya tus funcionalidades en su producto original. A mí esta opción me parece menos peligrosa, porque siempre es más difícil para un producto generalista servir a un nicho concreto.
• Si construimos sobre un producto que es open source, nuestro riesgo se reduce mucho y, prácticamente, se limita a que el desarrollador del producto decida competir directamente con nuestro servicio.
• La dimensión que puedes alcanzar siendo un wrapper está limitada. Al final el pastel realmente gordo se lo va a llevar la empresa que aporta la tecnología compleja. Por otro lado, crear tecnología compleja es caro, difícil y, en muchas ocasiones, acaba en fracaso. ¿Se puede crear un producto que facture un par de millones al año como un wrapper? Sin duda, y más ¿Se puede crear uno que facture 500 kilos? Es mucho más difícil.

Qué haría yo si tuviera que construir un wrapper

• Buscar un nicho que fuera relativamente pequeño. Cuanto más alejado de lo enterprise, menos jugoso será para empresas enormes, que suelen construir mercados desde arriba hacia abajo.
• Una vez definido mi cliente ideal, intentaría aproximar la solución hacia ellos lo máximo posible. Yendo hacia cosas muy concretas de ese mercado e intentando alejarme lo máximo posible de lo que vaya a construir el proveedor que a mí me da el servicio.
• Cuanto más nueva es una plataforma, más facilidades pondrá a la hora de permitir una integración. Cuanto más vaya madurando, más intentará conseguir que el negocio de los partners se mueva hacia ella. Litmus es un servicio de que permite analizar que los emails se vean correctamente en todos los dispositivos. Inicialmente permitía una integración con terceros, con la que consiguió convertirse en la solución de facto del mercado, ya que estaba integrada en muchísimas plataformas. Después, decidió ir a por el negocio que hacían estas plataformas con su producto, cambiando la integración por API a una por iframe y el coste de un fijo mensual a un Revenue share. Varios negocios que eran un wrapper con poco valor añadido sobre Litmus, tuvieron que cesar su actividad.
• Es un trabajo extra, pero una vez hubiera encontrado el product market fit, trataría de desacoplarme lo máximo posible del proveedor. Aquí no estamos hablando de utilizar marketplaces, si no de que nuestro producto se apoya mucho en APIs de servicios concretos. Intentaría integrar con varios servicios diferentes o incluso tratar de replicar esos servicios utilizando el Open Source. En definitiva, trataría de crear una vía de escape para mitigar el riesgo de plataforma.
• Si no haces tecnología, tienes que hacer producto. O lo que es lo mismo, si tú diferenciación no va a estar en la tecnología, debería estar en la UX y en la calidad de tu producto.

En resumen

Creo que esta forma de afrontar los problemas puede ser útil si no tenemos tiempo o dinero para estar años desarrollando un producto. Pero, si no eres capaz de diferenciarte bien y reducir tu dependencia de un único proveedor, debes tener claro que tienes una empresa con fecha de caducidad.

La clave es proporcionar un valor añadido suficiente para convertir nuestro producto en necesario para un nicho del mercado que nos permita subsistir e incluso financiar nuestra expansión hacia otros mercados.