Como algunos otros mencionados, soy un gran oponente de ser hostil a los clientes por defecto, algo por lo que la industria de licencias es conocida. Así que ampliaré una buena solución para su problema que también ofrece un buen cliente UX .
Para comenzar, mencionó que tiene una versión "limitada" de su software que está utilizando para tratar de convertir a los clientes a "actualizar" para obtener funciones adicionales. Así que lo que está buscando son las licencias de funciones de su producto, por ejemplo, un cliente puede comprar una licencia para funciones X o función-Y .
Construí Keygen con este tipo de licencia en mente. Keygen es una API REST de licencias que le permite administrar cuentas de usuario, licencias y también rastrear el uso / asociaciones de la máquina.
Lo que haría es configurar 2 tipos de licencia (una política dentro de Keygen) donde una es una política básica para la versión gratuita limitada y la otra es una política para la versión paga.
No estoy seguro de lo que está usando para los pagos, pero supongamos que está usando algo como Stripe (bastante estándar hoy en día) que ofrece webhooks . Keygen también tiene webhooks (ya sea que lo use o no, todo esto sigue siendo aplicable). Puede integrar Keygen para hablar con su proveedor de pagos utilizando webhooks de ambos lados (piense: customer.created-> crear una licencia base para el cliente, license.created-> cobrar al cliente por la nueva licencia).
Entonces, al utilizar webhooks, podemos automatizar la creación de licencias para nuevos clientes. Entonces, ¿qué pasa con la validación de la licencia dentro de la propia aplicación? Esto se puede hacer de varias maneras, pero la forma más popular es exigir a su cliente que ingrese una clave de licencia larga en un campo de entrada que luego puede validar; Creo que esta es una forma terrible de manejar la validación de la licencia en su aplicación.
¿Por qué pienso eso? En primer lugar, requiere que su cliente ingrese una clave de licencia tediosamente larga destinada al consumo de la máquina, y en segundo lugar, requiere que usted y su cliente realicen un seguimiento de dicha clave de licencia tediosamente larga .
Bien, entonces, ¿qué es una alternativa? Creo que la mejor alternativa es hacer algo a lo que estén acostumbrados todos sus clientes: permitirles crear una cuenta para su producto utilizando un correo electrónico / contraseña . Luego puede asociar todas sus licencias y sus máquinas con esa cuenta. Entonces, en lugar de ingresar una clave de licencia, simplemente pueden iniciar sesión con sus credenciales.
¿Qué ventaja te da eso? En primer lugar, elimina la necesidad de que usted y sus clientes realicen un seguimiento de las claves de licencia, ya que todo se maneja detrás de escena dentro de su cuenta de usuario y lo más importante: ahora puede ofrecer a sus clientes licencias y máquinas de autoservicio ¡activación! es decir, dado que todas sus licencias y máquinas están asociadas con su cuenta de usuario, puede solicitarles que compren una licencia cuando inicien su aplicación en una máquina no reconocida.
Ahora sobre validación de la licencia : cada vez que el cliente inicia sesión en la aplicación con su correo electrónico / contraseña, puede preguntar su cuenta de usuario para las licencias de su propiedad para determinar si pueden utilizar funciones X o función-Y . ¡Y dado que su aplicación ahora es de autoservicio , puede permitir que sus clientes compren funciones adicionales directamente desde su aplicación!
Por lo tanto, hemos introducido un montón de automatización en nuestro sistema de licencias, podemos otorgar licencias de funciones individuales (es decir, una versión limitada frente a la completa), hemos ofrecido una experiencia de usuario increíble para nuestros clientes y también hemos aliviado una de las principales razones para solicitudes de soporte: recuperación de clave de licencia.
De todos modos, esto se hizo largo, pero espero que ayude a alguien.