“Unravel Everything. Bring the future to us.” That’s the mission of Speee, a Tokyo-based digital transformation (DX) firm dedicated to data-driven links in business development. Speee is now broadly expanding their business activities, such as their real estate sales and appraisal service Ie-Uru as well as their home renovation company introduction service Nurikae, among a variety of other marketing DX businesses.
- Industry: Digital Transformation (Marketing and Real Estate)
- Number of Employees: Approx. 400 (as of January 2022)
Speee began operating an internally developed CMS, but they encountered problems in three areas: cost, usability, and stability.
We developed an in-house headless CMS in 2018 for our content creation and article management. However, when we actually started operating the system, we discovered several problems, which led us to consider replacing it. There were three issues at the time.
The first issue was an increase in development and operation costs.
It costs a lot to develop and operate a CMS in-house. However, since its scope is limited to internal usage within the company, a large return cannot be expected. That inevitability makes it difficult to invest in development and operation.
The second issue was usability.
Even though it was a CMS for internal use, it was essential to have an easy-to-use system in order to rapidly create high-quality content. Yet we lacked strong investment in development after the initial release due to high costs and low return on investment, as mentioned above.
As a result, no system improvements were made after the initial release, and content creators continued to use a very inconvenient UI and infrastructure. Without a doubt, that in turn led to lower-quality content.
Finally, the third issue was that the old CMS became a factor that reduced the stability of our other systems.
Since the CMS we developed in-house was a headless CMS, the actual content display was done by another web application. This web application needed to call the API of the headless CMS, but when this API went down, the entire web application would often go down as collateral damage.
Time for drastic measures to put an end to snowballing costs. The team looked toward a SaaS solution, with Kinsta rising to the top of of possible candidates.
Increased development costs had become a bottleneck, and so we decided to move to SaaS. The question was which SaaS to move to. From our research, we narrowed it down to a couple of candidates, including Kinsta, and there were three great things about Kinsta in particular that we focused on.
First, on Kinsta we can use WordPress, the most popular CMS in the world.
We already had a department in our company that was using WordPress, so we had some familiarity with it. Also, since many people use it for a wide variety of purposes, we recognized that its functionality and scalability are very appealing.
Second, Kinsta’s managed service has a broad reach.
Although it’s easy to get started with WordPress, it’s a headache to keep PHP and WordPress properly up to date. With Kinsta, PHP and WordPress updates can be done with just a few clicks, and CDN and domain management can be done from the UI. These were features we were looking for, as we wanted to focus on content creation and service development.
Third, Kinsta’s price is reasonable for the features.
With all of Kinsta’s rich managed features mentioned above, the price is relatively low compared to the services we were considering.
We chose Kinsta because of its superiority on the above three points in comparison to the competition.
With the combination of WordPress and Kinsta, their workflow became incredibly smooth. Plus, system stability improved immediately.
First of all, thanks to the switch from our own CMS to WordPress, we are now able to create high-quality content faster. This is thanks in large part to Kinsta’s high-quality UI and system design, as well as the assistance provided by its wide variety of powerful features.
In addition, since WordPress is so widely used, many content creators already have experience using it in the past. Even if they run into problems, solutions are readily available online, which reduces the cost of exposition and research.
The most remarkable thing for us is the stability of Kinsta’s system. Before we moved to Kinsta, every year we had several malfunctions that affected our users, but since migrating to Kinsta, those problems have completely disappeared. This is not only because Kinsta itself is highly stable, but also because the probability of failure has been reduced because we no longer need to link multiple systems through an API.
Another reason is that middleware and plugins are now kept properly updated. With our proprietary CMS in the past, updates of middleware and libraries tended to go neglected. Now, we use Kinsta’s functions to upgrade our PHP and WordPress versions, and we have created a mechanism for automatic plugin updates by maintaining CI/CD semi-automatically.
Kinsta is the solution to staff limitations; future-proofing is key.