Some thoughts on using Sitecore Habitat for Production codebase

Habitat is considered as a demo project to highlight HELIX principles on practice. While Sitecore don’t recommend using it for Production codebase, many sitecoreans still use it as a base for their Sitecore platform projects.

There are some people against this and there are lots of supporters. Main arguments of supporters would be that Habitat looks good, have lots of inbuilt functionality and is continuously developed by GitHub community.  Opponents claim that it is bad of using something that is not recommended by the platform vendor.

Apart from having some great features, habitat project comes with a set of npm/gulp scripts and free item synchronization framework (unicorn) that allows companies who are building their websites on Sitecore to save costs on early stages of a project. Your dev team would be grateful for having dev setup/deploy scripts that actually work from first attempt (assuming you have the right version of npm and gulp J). Your finance director would be happy that you’re using a free tool for team development and you don’t ask them to spend hundreds of dollars on purchasing the paid ones.

My own opinion is that there is nothing wrong in using Habitat as long as you know for sure what every line of code in your project is doing and understand consequences. You need to spend considerable amount of time to understand all foundation and feature projects. Understand which code you can re-use and which shouldn’t probably make its way to your source code. I find that the code base of Habitat has some really great features which are above and beyond better than the libraries developed in-house by digital agencies for their own use.

My resume is: try it, spend some time understanding it and build your own project base out of it.