Pros and Cons of Standard Marketplace Solutions for Website Development

Often, when developing a new site with “1C Bitrix” CMS, we can face a dilemma: is it better to create a unique site or to use a standard marketplace solution?

There are obvious and less obvious features connected with this issue. Let’s try to have a glance at them in this article.

When choosing a standard solution, we have in mind that its cost is much cheaper than that of the website created “from scratch”. Stages such as requirement specification, prototyping, layout design, slicing and programming are simply omitted. All these stages cost money, and if your business is on the initial phase of its development or if it is a nonprofit project, the much cheaper full-featured site will seem more attractive than one created on purpose at great costs.

And it also saves a lot of time. It takes as little as two hours to host a ready-made site and to handle its minimal tuning.

With such advantages at stake, it is easy to put up with the fact that the product is not unique, and somewhere there, dozens of tween-sites might circulate.

Sometimes, the functionality will also need adjustment and debugging, but it seems rather appropriate in terms of scope – two to twenty hours to fix small inconsistencies for a ready-made online store.

But this is where we fall into the first pitfall. It is expected that the solution bought on marketplace will work smoothly, and it will be subject to all the requirements for the mass product development. In practice though, it often happens that standard solutions are tightly gridded to the data presented on the demo-version of the site, and, for instance, when you try to change filtering options you suddenly find out that the way of standard template integration works badly. Indeed, to make the site work, you need not only make changes in catalog configurations, but to rewrite hardcode in several places. You should be 100% ready for several of those problems even if you deal with studios specialized on mass-market solutions.

Though, you will hardly find any information about such problems; if anything only in complaints from past clients. Though the problem might seem simple at first sight, it might take several hours for the programmer to manage it just because design and coding standard was violated, and nobody controlled it.

After a solution has been deployed, it may turn out that the developer tried to stray from regular components of the system whenever it was possible, replacing it with personal scripts even for things as trivial as news-lists. The programmers, when evaluating the cost of such functional debugging, will anticipate risks of the code being tangled and taking too much time to understand how to work with the contrasted programmer’s new script, and will include these risks into pricing.

To summarize briefly, all pros and cons are presented in the following table: