Kirby launched on January 9th, 2012. I abused the Zootool Twitter account to promote it a bit and sent out a newsletter to the beta testers, but that was all the launch marketing I could afford. Twitter worked really well at that point and Kirby managed to get quite some decent coverage. It seemed to hit a nerve at a time when systems started to get more and more complex. The performance in combination with the simple setup and easy to sync local and production environments were getting a lot of attention.
Despite the sceptics, Kirby made €600 in its first months and €14.000 in its first year. Not enough to be called a raving financial success, but definitely enough to justify some extra time and keep it going.
While Shaun Inman kept the source code for his apps behind closed doors, I wanted the same transparency open-source projects offered. Therefore, I put the entire source code for Kirby on Github. Seemingly madness. Why would anyone pay for it, when they can simply download it? The first versions of Kirby even came without a license check. But it worked. There were always enough customers who understood the principle of investing in enjoyable software. This principle still works for us today and has generated a very loyal customer base.
When Kirby launched, it was entirely built to be administrated on the file system. There was no web-based admin interface. You had to create folders and text files manually. The first sites were portfolios, personal blogs and a couple smaller company websites, but without an interface, Kirby was pretty useless for less technical people.
Our beta testers had asked for an interface plenty of times, and requests grew louder after the launch. So I pushed the first Panel version quite a bit and released it just 10 days after v1.0.
The first version of the Panel was simple. Users could edit site info and define fields for different page types with blueprints. Files for each page where shown in a simple list. User accounts were hardcoded. But it worked and opened Kirby to a larger audience.
In June 2012, I received one of the first code contributions for Kirby. One of our users submitted a way to load plugins from folders in the plugins directory instead of adding individual plugins as single PHP files. His name was Lukas, and he was quite good at PHP. He turned up with more and more contributions, issues and comments over the following weeks and months, and I was impressed how well the open-source principle worked despite the commercial model.
I learned a bit later that this guy was 15 at the time. You just have to love the internet sometimes. Lukas quickly became a constant in the Kirby community. Does the name sound familiar?
With a growing community and more customers, the demand for documentation and support also grew. It's one thing that has not changed in 10 years. Documentation is everything. Never underestimate the effect of good docs. We invest a lot of time in our documentation and support, and see it not just as a service for our users, but also as a marketing tool.
The very first effort to provide better docs for Kirby 1 was the famous cheat sheet. Today, I cannot believe I really created it in InDesign and published it as a PDF. It later turned into our reference … which is just slightly more extensive than that PDF.
How do you collect feedback and offer support for a brand new file-based CMS? Stupid question! You build a file-based forum of course.
The first forum launched in May 2012 and ran for almost 3 years. The code was shoehorned into a plugin and had weird hacks all over the place. The folder system was pretty straight forward though:
Authentication was handled through Twitter. Over the years, thousands of threads and posts were created and it held up quite nicely. But it missed a lot of essential community features. There was no notification system, no proper way to see new replies or any other form of activity.
I was really impressed by the performance of the file system and pleased by that first forum version. After all, my focus was on Kirby and not the forum itself. I never questioned the effects on the community. Conversations weren’t really working well and overall engagement was pretty poor.
When we switched from our self-made mess to Discourse in 2015, the community really took off. Support requests via email were instantly cut in half. It’s sometimes not very clever to build your own tools, when your focus should be on your main product.