What we’re coming from
For the past several years, we’ve built the majority of our websites using our own proprietary CMS, Ensō. It’s built on top of Laravel, opting for Vue.js as our javascript library and Tailwind for our css.
From the perspective of a developer, it has been great. We’ve been fully in control of the way that our framework has developed and can say with absolute certainty that we know how the system works because… well, we built it. It’s also had the side benefit that through the process of building our own CMS, we’ve become far more knowledgable about the inner workings of Laravel than we would have become otherwise.
However, we’ve reached a fork in the road and have a major choice to make. Should we keep on going with Ensō? If we’re honest, that question is really easy to answer.
Realistically, we can’t stick with Ensō.
We may not be totally impartial, but we think Ensō is really good. However, one of the biggest stumbling blocks with having it as our primary offering is that a large number of jobs we could pitch for want us to build something in an open source, known framework. And by “known”, what they really mean is that it needs to be popular and have a thriving ecosystem. There’s practically the underlying implication; it should be Wordpress.
This is an entirely reasonable request. While Laravel itself is open source and any Laravel developer should be able to jump in and get up to speed on working with Ensō fairly quickly, that’s not what they’re after.
To be able to fulfil that kind of brief, we would need to invest a lot more time, effort and money into Ensō. Firstly, we’d need to open source our code. While we can make that happen easily, it also means going over the whole codebase and making sure that the documentation is not only good enough for us here at Maya to understand, but also good enough for any novice developer to pick up easily. Probably sanitise the code comments too… I imagine there some angry rumblings in there somewhere about how we’ve had to make some workaround for some dependency (useful if things change, but perhaps not so professional).
Next, we’d need to put together a marketing budget and actively push to get people using it. And if we’re even successful there, we’d also be making a lifetime commitment to continue to work on the CMS, because a stagnant CMS is not going to be popular for long. Technically, we could structure it in such a way as to monetise the end results, but that was never the purpose of Ensō. It was build to make our lives easier in building beautiful, fast and easy to use websites for our clients. That’s the real goal here.
So, what are the alternatives?
We are viewing this decision as an opportunity, using it to update the way that we work with Laravel. When we originally chose to build Ensō, it was off the back of research we’d undertaken into existing Laravel-based CMSs. There were a few, with varying degrees of popularity, but we didn’t find one that really met our needs. Either documentation was poor, functionality wasn’t there or there just wasn’t any sort of ecosystem.
Now though, the landscape is very different. We found a couple of CMS options that are really good and rival Ensō in functionality, but also meet the other requirements where it falls short. We’ve focusing on using either Statmic or Twill. They are both open source and have decent communities and ecosystems, allowing us to tailor our offerings to specific client requirements and budgets.
The other big advantage to this approach is that it doesn’t mean we have to call time on our Ensō based websites either. Ensō was always written purely as a CMS, so the frontend of the site is completely separate. We’ll be able to drop either Statamic or Twill into existing projects, strip out Ensō and have something very comparable to move forward with.
So, just more Laravel then?
Not at all. Many years ago, we built a number of Wordpress sites. Some of them we still maintain. Back then though, Wordpress was the go-to for most of our projects. For every point in favour of Wordpress in terms of client/workflow benefit though, our developers ran up against some functional impracticality of using Wordpress to attempt do more than it was intended to do. In fact, there was such frustration with it that it became one of the many reasons for developing Ensō.
Some things haven’t changed. Wordpress’ database structure is still horrendous. Put too many plugins on your site, and you’ll still slow your site down, not to mention the pain of trying to keep core Wordpress up to date and making sure all the plugins work with it.
Other things have changed though. Wordpress itself has gotten better, as have the means to work with Wordpress. roots.io have put together some great tooling for developers to improve the experience of working with Wordpress. Better still, their Sage starter theme uses Blade templates and easily allows us to switch in Tailwind, letting us keep working with our existing tool choices.
We’ll still have to be mindful that we don’t try and push Wordpress too far beyond what it’s good at, but having it as a tool we can employ when it fits the job will be a useful. It is a hugely popular blogging platform for a reason.
Anything else?
Sure. One of our recent projects has needed to incorporate an app, a website and some online store functionality. At it’s current size, we could conceivably have built this as a Wordpress site, thrown on WooCommerce and crossed our fingers that it didn’t grow too big (which is really not the way to do things).
We looked into several Laravel-based systems and felt that they didn’t offer what we were after, would have been way over budget or a lot of work to implement even something basic. Finally, decide to settle further afield and we work with Shopify (more specifically, using Shopify as a backend and connecting via API so that website and app can work independently with the same data).
We’ve dabbled with Shopify before, so this isn’t really a new development for us, but it does go towards cementing our updated outlook when it comes to bidding for, developing and most importantly, enjoying client work.
Our goal
We’re expanding what we do. Instead of trying to expand by building more systems and trying to become experts in every little detail, we’ll be utilising more existing options. It’ll reduce work, speed up planning and development and ultimately mean we can offer better value for money for our customers without compromising the quality of our work.
