Sure, it might be a project need to switch the underlying CMS or even programming language.
Let’s say the project started with something small or medium-sized and Kirby + one or two custom plugins were a good fit. You were comfortable with Kirby and plain PHP so you were more productive with that CMS than with having to configure and restrict a more heavyweight CMS (Drupal, WordPress even…). So that’s how the project got done.
Then the client comes up with needs for evolving or redesigning the website, big new features, lots more content or user-provided data, etc. Maybe there’s a need to integrate data from a webservice that serves hundreds of megabytes of JSON content that needs to be cached locally in a database and updated every night? That’s a new project in and of itself. So you evaluate your choices:
- What would it cost to do it with Kirby + PHP + maybe a custom MySQL database?
- What would it cost with this or that heavyweight CMS and some plugins/modules that seem to meet the client’s needs?
- Or maybe a hybrid approach where you have Kirby for the information parts and maybe a different application for serving other pages or fragments of pages, managing a database and CRUD operations, etc. Perhaps a Kirby+Laravel hybrid?
And for each solution, asking not only how much it would cost to do it but: would the result be reliable and easy to expand upon in the future?
Also, consider that a project’s “growing needs” doesn’t just imply tech choices. Most importantly, it implies available skills and time. If you’re a web designer with HTML+CSS skills, and just a bit of PHP (or other programming language) skills, which is perfectly alright of course, you can set up a simple project with Kirby but when the project needs become more complex they are not growing out of Kirby, they are growing out of you. As in, a single-person team with mostly front-end skills and no database / data / storage / devops / deployment skills. You then need more people (and time and money) to complete the team’s skill-set, and maybe the tech choices will go towards a different tech stack but maybe it will still build on Kirby.
That’s a bit like when Twitter started with a Ruby On Rails website but it couldn’t keep up with the load at all, and they rewrote most of their website. They must have seen many more rewrites of different services since then. In my opinion they didn’t grow out of Ruby On Rails per se, they grew out of having few server/ops/data people in their team to begin with and being late to address those needs. Maybe ditching Ruby On Rails was a given, but let’s not look at the wrong things here: the important part is the skills and people and resources, and planning/investing ahead. The tech choices (and changes and partial rewrites) must come, but they’re a secondary concern: if you don’t have anyone on staff to see (and foresee) the needs and do the evolutions (on top of your existing stack) or partial rewrites (swapping limited bits of your existing stack for more capable implementations), it won’t help one bit that you know that Kirby+PHP can do a lot or that a switch to a big Drupal or Laravel-based CMS is an option. 