Hace ya casi una semana que di a luz al niño.
El proceso de actualización en sí está siendo bastante tranquilo, al menos bastante más tranquilo de lo que me temía. Y es que, como todo programador / técnico de sistemas / persona de bien, creo firmemente que si algo no está roto, no hay necesidad de arreglarlo. O mejor aún, si algo funciona, lo mejor es ni acercarse a ello, no se vaya a enfadar.
Todo esto viene a que Keep Your Word 2 (fabuloso organizador de vocabulario y flashcards para Mac e iPhone, hagamos un poco de SEO), es una actualización de pago. Lo que tiene su importancia si tenemos en consideración los
Antecedentes
Hace ya año y medio, cuando lancé la primera versión pública de la aplicación, lo hice apoyándome en Kagi para procesar las ventas. La razón principal de usar Kagi, y no otros procesadores de cobros, fue que era lo más fácil de montar. Preparar una tienda con un producto es bastante rápido, y ellos mismos proporcionan la generación del número de serie, y el código necesario para comprobar los números de serie en la propia aplicación.
Para un primerizo en estas lides del shareware, era la solución más sencilla, que menos tiempo me quitaba de aquello en lo que realmente necesitaba invertir más tiempo: la aplicación en sí. Resumiendo, con Kagi podía tener cupones de descuento, generación de número de serie y comprobación en cliente en unas tres horas.
Sin embargo, desde el primer momento me quedó claro que el sistema tenía varios puntos débiles, el principal de todos ellos, la integración con el resto de mi web. La tienda podía llegar a integrarse visualmente con el resto de mi web, pero no sin dedicarle mucho tiempo y esfuerzo.
Al irse acercando el momento de empezar a pensar en lanzar el upgrade a la versión 2.0, se hizo evidente otro problema con Kagi: ¿cómo gestionar las actualizaciones? Lo normal es ofrecer la actualización a los que compraron una licencia para la versión 1.x a un precio reducido (en mi caso, con un 40% de descuento).
Hay que tener en cuenta que la tienda que ofrece Kagi no permite añadir ninguna lógica personalizada. El flujo está prefijado, y no es configurable: primero página de productos, después entrada de datos del comprador, terminando con página con confirmación del pedido y entrega del número de serie. No hay forma de hacer algo como esto, hacer al usuario introducir su número de serie actual (de la 1.x), comprobar su validez, y abrir una venta al precio con descuento. Tampoco era posible ofrecer la actualización gratis a los que hubieran comprado la 1.x en los últimos 90 días.
El soporte de Kagi me ofreció una solución un poco pintoresca: crear un descuento del 40%, y asignarle tantos cupones de descuento como usuarios hubiera de la 1.x, haciendo que cada uno de esos cupones fuera uno de los números de serie válidos. Así, al ofrecer el update, comunicar a los usuarios que tenían que introducir su número de serie actual como cupón de descuento para comprar el nuevo serial.
Obviamente, la solución, aunque técnicamente posible, rechina malamente: y es que nadie lee lo que sale en pantalla, y punto pelota. Así que me temía a) tener que explicar 300 veces que para comprar el serial nuevo hay que meter el viejo como cupón de descuento y b) tener que devolver el dinero a muchos que iban a hacer la compra del serial nuevo sin meter el viejo, y por tanto sin descuento.
Total, que se mire como se mire, la solución era más bien mala.
Si a eso le añadimos que Kagi no proporciona una forma de recuperar el número de serie a los usuarios que lo hayan olvidado/perdido, cada vez se iba haciendo más claro que la solución a todos los problemas tenía que pasar por…
Tienda a medida
Si necesito poder comprobar que un número de serie es válido y existe en mi base de datos antes de proceder a la venta, si quiero hacer cosas como promociones puntuales cuando saque el siguiente producto de pago, si quiero dar un formulario donde la gente se pueda recuperar el número de serie por sí misma, si quiero control total sobre lo que sale y cómo sale en mi tienda, tengo que hacerme yo la tienda. Punto.
Obviamente, la primera opción que consideré fue instalar Potion Store, pero ni tengo cuenta Website Payments Pro, ni es que sea muy leído y escribido en Rails, ni puede decirse que me guste lidiar con Paypal.
Como en el momento en el que estaba buscando la solución para la tienda me acababa de quedar colgado con un proyecto terminado pero no entregado que había desarrollado en CakePHP, y la verdad es que el framework me había hecho bastante gracia, aproveché la inercia, y me decidí a hacer una gestor muy sencillo para la nueva tienda de bambooapps.
El problema, no obstante, era el procesador de pagos. Podía hacer que fuera Paypal, pero al no poder tener cuenta Payments Pro, la única opción es lanzar al comprador fuera de mi web, hacia Paypal, y esperar que la compra se cierre correctamente, para que al volver a mi servidor, pueda generar el número de serie. Además, Paypal oscurece cada vez más la posibilidad de pagar sin tener cuenta de usuario en su servicio, lo que me hacía temer que podía perder alguna que otra venta. Y no estamos para regalar el dinero.
Y aquí es cuando llegamos a…
FastSpring
FastSpring tiene buenas reviews, y fama de ofrecer un servicio al usuario de primera. Y sobre todo, el haber visto tiendas de otros desarrolladores perfectamente integradas con el resto de sus sitios web.
La primera impresión al abrir una cuenta fue muy buena. Nada más pedir el alta, recibí un email pidiéndome unos cuantos datos básicos sobre mi producto (nombre, precio, icono…) y en unas dos horas ya tenía una tienda funcional, con la que ya podría haber empezado a vender KYWs como rosquillas.
La personalización de sus páginas es muy sencilla (básicamente una plantilla que envuelve a la de ellos), y aunque el proceso de venta en sí también es bastante rígido (presentación de producto-> confirmación de pedido -> entrega serial), el sistema permite varios grados de flexibilidad más que Kagi. Para empezar, pueden embeberse cupones de descuento y otra información en la url, lo que me permite lanzar desde mi tienda en CakePHP todo tipo de ofertas, cross-selling, upselling, etc.
Otra cosa que me ha gustado de FastSpring, y de la que no me di cuenta hasta no empezar a trastear con su sistema, es lo fácil que es integrar la tienda con un generador de números de serie en mi servidor. Al contrario que Kagi, que aunque también permite generar el serial en tu servidor, requiere de un proceso administrativo de casi una semana para dar de alta la opción, basta con introducir la url de tu generador en la administración de FastSpring, asignar user y password para securizar la comunicación, y decidir qué quieres enviar a tu servidor, y qué quieres que éste conteste al suyo.
De esa forma, yo controlo qué quiero cobrar y cómo, paso el control a FastSpring, que en un interfaz completamente integrado con el mío, gestiona el cargo a la tarjeta, pide a mi servidor el serial, y se lo entrega al usuario. Obviamente, yo también aprovecho ese momento para automatizar una serie de cosas en mi lado, como el registro del nombre, email y serial del usuario en mi base de datos, alta en mi lista de correo, o la emisión de un email con la licencia.
El sistema sigue sin ser perfecto, sigue habiendo un punto del proceso donde pierdo el control del mismo, y hay un punto en el que todo depende de que dos servidores se entiendan sin problemas, así que sigue habiendo fricciones. No obstante, los riesgos son mucho menores que las ganancias con el nuevo sistema.
Y alguno se preguntará… ¿por qué cuentas todo esto? La verdad es que no lo sé. Imagino que por enfatizar un aspecto del desarrollo de software que siempre me ha parecido el más importante: el refinamiento sucesivo, el intentar montar algo que funcione adecuadamente con el mínimo de recursos aceptables, hacerlo público, sacarlo por la puerta, y a partir de ese momento, ir mejorándolo, ir engordándolo, de forma constante, añadiendo mejoras cuando sea necesario añadirlas, y refactorizando procesos cuando sea necesario hacerlo.
O dicho de otra forma, es muy probable que si hubiera tenido que montar mi propia tienda, con mi propio generador de números de serie, integrado con una tercera parte para procesar los pagos, no hubiera sacado la 1.0 nunca.
