Magento vs in-house solution

I recently came across a business who decided to move away from Magento to using their own in-house solution, albeit without the features of Magento, but something they are willing to invest the time and money in building into their in-house platform, their primary reason for doing this? Because they could not find a full time developer in their area and for their budgeted salary, and this they felt posed a long term business threat.

This is something many business’s consider when first starting an ecommerce shop, which platform to use, outsource or insource, opensource or bespoke?

It’s a choice that can only be worked out by looking at how much time you have, your budget, and technical resources you can allocate to a project.

I can see how some business owners might get frustrated with Magento, something which could be considered a niche area. The stats website builtwith suggests around 1% of the top 1 million websites are built with Magento, at first the seems rather pathetic but the huge variety of platforms out there makes this number pretty reasonable. Shopify for example only has half this figure or IBM Websphere a mere 0.2%. Not that being popular should be the only reason to choose a platform.

There are less developers than there are for standard PHP but it’s no different from using Ruby,Shopify or requiring an iOS developer to develop an app a specific ecommerce platform is a specialist area that’s a no brainer.

And then there’s the logic of building a complex ecommerce system in-house that only those developers know, what happens when the founding devs leave the business? Your left in an even worse situation. Having a community around your business gives you some extra security, tried and tested code, security patches, accredited professionals and documentation.

Magento is one of the few applications that gives you total control of your shop in an unprecedented way. Allowing all sorts of configurations that the initial Magento team probably never even dreamt the platform would be used for.

And here in lies the issue, when you do have a heavily customised platform especially one with 3rd party extensions, it can be become cumbersome in updating and supporting. In this case there are lots of areas of the site where products are only shown if some other conditions are met, this kind of logic on top of Magento’s default requirements for a product to be visible on the site creates a lot of support queries. As a developer you will often get the query of “why is this product not showing” and 99% of the time it’s because a field isn’t set or a in a particular scope a field isn’t set, the product is out of stock etc. Sometimes you don’t know yourself , I’ve spent countless hours looking into these type of queries. Part of the solution to that is more training for the people who use the backend and serving up a FAQ or decision tree that helps the user figure out why.

The second issue with Magento is that if you do get a reasonable amount of traffic or sales everyday, is that you either need a dedicated Magento hosting specialist or people on your team that know how to manage servers. And if you’ve gotten to that level in comes the caching headache.

But these are problems any platform faces one I feel with a small in-house team will not easily be overcome unless it’s built with a similar flexible design pattern and you have a broad skillset based team. Magento comes into it’s own when you want a site that is rich in functionality but don’t have time to develop whole eco systems to deliver that idea, like templating, multi-currency, multi scopes and hole punching, user authentication and REST Api’s and really why do it unless you have something that’s really taking ecommerce in a different direction.

What does matter is getting the configuration right from day one, finding an experienced developer or agency who has a proven track record of Magento development and scoping out a project development roadmap that looks at how the various parts of the site work together. Limit the use of 3rd party modules to only be used where it will save a substantial amount of development time and make sure they don’t interfere with any custom functionality you plan to have.

3rd party modules work best where you need core parts of functionality like payment gateways, as that’s where substantial costs can be saved not having to develop your own interface as your unlikely to want to customise these at a later date.

After that if you plan on having a lot of features for example customer points, promotions and lots of rules about how the products are displayed it may be better to size up the development costs rather than using a lot of different 3rd party modules as it can take just as much time writing the code that communicates between them.

In my view this is a much better, long term and cost effective route than going completely for a bespoke ecommerce solution.