«Desentrañar todo. Acercanos el futuro». Esa es la misión de Speee, una empresa de transformación digital (DX) con sede en Tokio dedicada a las conexiones impulsadas por datos en el desarrollo empresarial. En la actualidad, Speee está expandiendo ampliamente sus actividades empresariales, como su servicio de tasación y venta de bienes inmuebles Ie-Uru, así como su servicio de creación de empresas de reformas del hogar Nurikae, entre otra variedad de negocios de marketing DX.
Instantánea
- Sector: Transformación Digital (Marketing e Inmobiliario)
- Número de empleados: Aproximadamente 400 (en enero de 2022)
El Problema
Speee empezó a utilizar un CMS desarrollado internamente, pero se encontraron con problemas en tres áreas: coste, usabilidad y estabilidad.
En 2018 desarrollamos un CMS interno para la creación de contenidos y la gestión de artículos. Sin embargo, cuando empezamos a utilizarlo, descubrimos varios problemas, lo que nos llevó a plantearnos sustituirlo. En aquel momento había tres problemas.
El primero era el aumento de los costes de desarrollo y funcionamiento.
Cuesta mucho desarrollar y hacer funcionar un CMS internamente. Sin embargo, como su alcance se limita al uso interno dentro de la empresa, no cabe esperar un gran rendimiento. Esa inevitabilidad dificulta la inversión en desarrollo y funcionamiento.
La segunda cuestión era la usabilidad.
Aunque se trataba de un CMS para uso interno, era esencial disponer de un sistema fácil de usar para crear rápidamente contenidos de alta calidad. Sin embargo, carecíamos de una fuerte inversión en desarrollo tras el lanzamiento inicial, debido a los elevados costes y al bajo rendimiento de la inversión, como ya se ha mencionado.
Como resultado, no se introdujeron mejoras en el sistema tras el lanzamiento inicial, y los creadores de contenidos siguieron utilizando una interfaz de usuario y una infraestructura muy incómodas. Sin duda, eso a su vez dio lugar a contenidos de menor calidad.
Por último, el tercer problema fue que el antiguo CMS se convirtió en un factor que redujo la estabilidad de nuestros otros sistemas.
Como el CMS que desarrollamos internamente era un CMS headless, la visualización real del contenido la realizaba otra aplicación web. Esta aplicación web necesitaba llamar a la API del CMS headless, pero cuando esta API se caía, toda la aplicación web se caía a menudo como daño colateral.
La Solución
Era hora de tomar medidas drásticas para acabar con los costes crecientes. El equipo buscó una solución SaaS, y Kinsta se situó a la cabeza de los posibles candidatos.
El aumento de los costes de desarrollo se había convertido en un cuello de botella, por lo que decidimos pasarnos al SaaS. La cuestión era a qué SaaS pasarnos. A partir de nuestra investigación, lo redujimos a un par de candidatos, entre ellos Kinsta, y nos centramos en tres grandes cosas de Kinsta en particular.
En primer lugar, en Kinsta podemos utilizar WordPress, el CMS más popular del mundo.
Ya teníamos un departamento en nuestra empresa que utilizaba WordPress, así que estábamos familiarizados con él. Además, como mucha gente lo utiliza para una gran variedad de propósitos, reconocimos que su funcionalidad y escalabilidad son muy atractivas.
En segundo lugar, el servicio gestionado de Kinsta tiene un amplio alcance.
Aunque es fácil empezar con WordPress, es un quebradero de cabeza mantener PHP y WordPress debidamente actualizados. Con Kinsta, las actualizaciones de PHP y WordPress se pueden hacer con unos pocos clics, y la gestión de CDN y dominios se puede hacer desde la interfaz de usuario. Estas eran las características que buscábamos, ya que queríamos centrarnos en la creación de contenidos y el desarrollo de servicios.
En tercer lugar, el precio de Kinsta es razonable para las prestaciones.
Con todas las potentes funciones de gestión de Kinsta mencionadas anteriormente, el precio es relativamente bajo en comparación con los servicios que estábamos considerando.
Elegimos Kinsta por su superioridad en los tres puntos anteriores en comparación con la competencia.
El Resultado
Con la combinación de WordPress y Kinsta, su flujo de trabajo se volvió increíblemente fluido. Además, la estabilidad del sistema mejoró inmediatamente.
En primer lugar, gracias al cambio de nuestro propio CMS a WordPress, ahora podemos crear contenidos de alta calidad más rápidamente. Esto se debe en gran parte a la interfaz de usuario y al diseño del sistema de alta calidad de Kinsta, así como a la ayuda que proporciona su amplia variedad de potentes funciones.
Además, como WordPress está tan extendido, muchos creadores de contenidos ya tienen experiencia previa en su uso. Incluso si se encuentran con problemas, las soluciones están fácilmente disponibles en Internet, lo que reduce el coste de exposición e investigación.
Lo más destacable para nosotros es la estabilidad del sistema de Kinsta. Antes de pasarnos a Kinsta, todos los años teníamos varias averías que afectaban a nuestros usuarios, pero desde que migramos a Kinsta, esos problemas han desaparecido por completo. Esto se debe no sólo a que Kinsta en sí es muy estable, sino también a que se ha reducido la probabilidad de fallos porque ya no necesitamos vincular varios sistemas a través de una API.
Otra razón es que ahora el middleware y los plugins se mantienen debidamente actualizados. Con nuestro CMS propietario en el pasado, las actualizaciones del middleware y las bibliotecas tendían a descuidarse. Ahora, utilizamos las funciones de Kinsta para actualizar nuestras versiones de PHP y WordPress, y hemos creado un mecanismo de actualizaciones automáticas de plugins mediante el mantenimiento semiautomático de CI/CD.
Kinsta es la solución a las limitaciones de personal; la clave es estar preparados para el futuro.
speee.jp
