”Lös upp allt. Ta framtiden till oss.” Det är målet för Speee, ett Tokyo-baserat företag inom digital transformation (DX). De arbetar med data-drivna länkar inom affärsutveckling. Speee expanderar nu sin affärsverksamhet på bred front, exempelvis med fastighetsförsäljnings- och värderingstjänsten Ie-Uru och introduktionstjänsten Nurikae för renoveringsföretag. De har dessutom en rad andra DX-verksamheter inom marknadsföring.
Ögonblicksbild
- Bransch: Digital transformation (marknadsföring och fastigheter)
- Antal anställda: Ca 400 (i januari 2022)
Problemet
Speee började att använda ett internt utvecklat CMS. De stötte dock på problem inom tre områden: kostnad, användbarhet och stabilitet.
Vi utvecklade ett internt huvudlöst CMS under 2018 för vårt innehålls-skapande och vår artikel-hantering. Men när vi faktiskt började använda systemet upptäckte vi flera problem. Vi började därför överväga att byta ut det. Det fanns tre problem vid den tidpunkten.
Det första problemet var ökade utvecklings- och driftskostnader.
Det kostar mycket att utveckla och driva ett CMS in-house. Användningsområdet är ju dock begränsat till intern användning inom företaget. Som ett resultat kan man inte förvänta sig någon större avkastning. Denna oundviklighet gör det därför svårt att investera i utveckling och drift.
Den andra frågan var användbarheten.
Även om det var ett CMS för internt bruk var det viktigt att ha ett lättanvänt system för att snabbt kunna skapa innehåll av hög kvalitet. Vi saknade dock starka investeringar i utveckling efter den första lanseringen. Detta berodde exempelvis på höga kostnader och låg avkastning på investeringen, som nämnts ovan.
Resultatet blev att inga system-förbättringar gjordes efter den första versionen. Innehålls-skaparna fortsatte dessutom att använda ett mycket obekvämt användargränssnitt och en klumpig infrastruktur. Detta ledde utan tvekan till innehåll av lägre kvalitet.
Slutligen var det tredje problemet att det gamla CMS-systemet blev en faktor som minskade stabiliteten i våra andra system.
Eftersom det CMS som vi utvecklade internt var ett huvudlöst CMS sköttes den faktiska visningen av innehållet av en annan webb-applikation. Denna webb-applikation behövde anropa API: n för det huvudlösa CMS: et. När denna API gick ner, kraschade dock hela webb-applikationen som en oavsiktlig skada.
Lösningen
Det var dags för drastiska åtgärder för att få ett slut på de snöbolls-liknande kostnaderna. Teamet tittade på en SaaS-lösning, där Kinsta hamnade högst upp på listan över möjliga kandidater.
Ökade utvecklingskostnader hade blivit en flaskhals. Vi bestämde oss därför för att gå över till SaaS. Frågan var bara vilken SaaS som vi skulle välja. Vår efterforskning begränsade detta till ett par kandidater, inklusive Kinsta. Det fanns exempelvis tre bra saker med Kinsta som vi fokuserade på.
För det första nyttjar Kinsta WordPress, det mest populära CMS: et i världen.
Vi hade redan en avdelning i vårt företag som använde WordPress, och hade därför en viss kännedom om detta. Eftersom många människor använder det för en mängd olika ändamål insåg vi dessutom att dess funktionalitet och skalbarhet är mycket tilltalande.
För det andra har Kinsta’s hanterade tjänst en bred räckvidd.
Även om det är lätt att komma igång med WordPress, är det en huvudvärk att hålla PHP och WordPress korrekt uppdaterade. Med Kinsta kan PHP- och WordPress-uppdateringar göras med bara några klick. CDN- och domän-hantering kan dessutom göras från användargränssnittet. Det här var funktioner som vi letade efter, eftersom vi ville fokusera på innehålls-skapande och tjänsteutveckling.
För det tredje är Kinsta’s pris rimligt för funktionerna.
Med alla rika hanterade funktioner hos Kinsta som nämns ovan, är priset relativt lågt jämfört med de tjänster som vi övervägde.
Vi valde därför Kinsta tack vare dess överlägsenhet på ovanstående tre punkter i jämförelse med konkurrenterna.
Resultatet
Med kombinationen av WordPress och Kinsta blev deras arbetsflöde otroligt smidigt. Dessutom förbättrades systemstabiliteten omedelbart.
Först och främst, tack vare bytet från vårt eget CMS till WordPress, kan vi nu skapa högkvalitativt innehåll snabbare. Detta är till stor del tack vare Kinsta’s högkvalitativa UI och systemdesign. Det beror dessutom på det stöd som tillhandahålls för dess breda utbud av kraftfulla funktioner.
Dessutom, eftersom WordPress är så allmänt använt, har många innehålls-skapare redan erfarenhet av att använda det tidigare. Även om de stöter på problem finns lösningarna lätt tillgängliga online. Som ett resultat minskar kostnaderna för felsökning och efterforskning.
Det mest anmärkningsvärda för oss är stabiliteten i Kinsta’s system. Innan vi flyttade till Kinsta hade vi flera funktionsstörningar varje år som påverkade våra användare. Efter till Kinsta har dessa problem dock försvunnit helt. Detta beror inte bara på att Kinsta i sig är mycket stabilt. Sannolikheten för fel har dessutom minskat eftersom vi inte längre behöver länka flera system via ett API.
En annan anledning är att middleware och plugins nu hålls ordentligt uppdaterade. Med vårt egenutvecklade CMS tidigare tenderade uppdateringar av middleware och bibliotek att försummas. Nu använder vi Kinsta’s funktioner för att uppgradera våra PHP- och WordPress-versioner. Vi har även skapat en mekanism för automatiska plugin-uppdateringar genom att upprätthålla CI/CD halvautomatiskt.
Kinsta är lösningen på personalbegränsningar; framtidssäkring är nyckeln.
speee.jp
