Collection Privée

08.01.2013 on 13:09 • edited 08.01.2014 on 19:33, rev. 7 • no comments tagged - sales, shopping, site
Project screenshot
Project screenshot
Project screenshot

About CP

Collection Privée was founded in 2009 by Antoine Poissonier to sell clothing and accessories in Russia using a flash-sale model. They had inherited the existing code from a French site ot theirs that they reused to set up a Russian internet shop. In time they opened a showroom in Moscow, a separate office and cloned their main site, thus spawning two other shops with different brandings.

The company closed down on August, 2012. Apparently, they ran out of money even to pay their own employees (not to mention the freelancer involved).


As the main site had been based on a rather ancient French code that was eventually altered by a lot of different people, in time the code became unstructured, poorly-documented and generally sloppy. Critical errors with detrimental effect to the database started to crop up, and these had to be fixed. On top of that various departments had a list of what extras were required to facilitate their operation. This resulted in the following list of notable tasks:

  • Fixing and (re)implementing the order status tracking system and making sure the real stock numbers and those in the databases are constantly in sync;
  • Bringing up the newsletter system and subscriptions back in order, so those who unsubscribe receive no more mails;
  • Debugging the configuration of a local accounting system that conflicted with the shop database (1C);
  • Implementing new statistics gatherers and reports for the managerial staff to give a detailed picture of what was going on in sales;
  • Integration with an online payment system (ASSIST, in this case);
  • Integration of a third party online booking services into the newly created site section devoted solely to that;
  • Allowing third party shops to do commission sales by implementing an appropriate export interface;
  • Better integration with the courier service by serving them proper data on orders they have to execute;

Because there were too many smaller tasks with poorly-quantifiable costs, we decided to work on a per-hour basis. This, and the fact that most work was done in the company's office to lower the communication overhead, lead to the lack of any extensive logs of tasks performed. The above responsibilities are therefore just the highlights. In fact at the time there were no IT specialists employed in the company, so everything at least slightly related to IT was relayed to yours truly.

TL;DR: below is more detailed info on how the company collapsed and my own speculations on how the poor state of local IT could have had an influence in that. Feel free to skip these subjective thoughts.


The company eventually collapsed - this happened in August 2012 right after I returned from vacation. This prevented me to collect part of my final payment, because there was no money to pay the employees, let alone a man signing the civil-legal contract. It happened suddenly and without warning: before I left, the company was extending their range of services and was into signing more partnerships. Some say they just suddenly ran out of money. A strange story.

I think the persisting problems with the internet shops, the accounting database mixed with the lack of common IT advice played a contributing role in the deterioration of that business. The problem is: you have serious lingering problems with your stock that constantly lead to lots of cancelled orders, the only thing you do here is try to make some cosmetic fixes without looking into the roots of the problem. Yet you want to expand and create additional functionality on top of a crumbling structure. I wasn't there to advice on stuff and offer to fix everything completely - in fact, it was impossible for me, because the company lost technical access to their shops, there was only a live, production version with almost no maintenance access to it. The fix would cost too much in terms of time spent and site downtime.

More on that in the technical part, because it's hard to describe the problem in layman's terms.

The general moral of the story: you don't hire specialists just to do the job you want them to do. Everything you need done shouldn't be handed to an executor in the "make me this" form. One should relay the requirements for something and listen to the suggestions on the various ways to implement the task, not to enforce the way something is to be done. This concerns programming, but is also actual for design and even common tasks.


This part is mostly about how things were done in the company and how they generally shouldn't be.

  • The hosting for the sites was switched to a french server at some point. There was only an FTP access to the site, no SSH, root access. So no crontab, no realtime log-based debugging. The sheer weight of the site meant that one couldn't get a site dump for testing purposes, let alone backup everything. The hosting company seemed to make money out of standard technical requests only they had the credentials to perform. Another funny thing: that was a dedicated expensive server.
  • The company used 1C-Accounting for relevant tasks, and the program worked with a local database which constantly synced with the remote one, used by the internet shops. The sync script ran every minute and took some 40 seconds to finish. One could only guess when in future this whole system would come to a full stop. Database desyncs were also a common case there.
  • The site used some makeshift object-oriented MVC model, but only the older core pages took advantage of that. By the looks of the code it seemed that some 4-5 people participated in the "evolution" of the site. Some pages were written with plain PHP without the existing libraries, most code lacked any comments. There was no common coding standard, no documentation for the past work. Most people apparently did a one-time job there without bothering to think about the future of the company.
  • When the company decided to create two additional clone-like shops, some genius thought that it would be cool to use the dev version of the site to host the second shop. That's how the company lost their development infrastructure.
  • The site stock system stored the current amount of goods in stock. If the order is created, the stock numbers diminish, if the order is cancelled, the stock is filled back. There is also a partial order delivery where you take only the cancelled goods into account when updating the stock back. The site utilized the textual order status in Russian, and the texts were hard-coded both in the shop site (in front-end, in back-end and everywhere the order could be altered) and the accounting program (which required to re-sync with the shop database after editing the order). Then the company decided they needed some new status texts. Though the whole thing was just unmaintainable. It took me much to clean up all the code for the site and relay the 1C-configuring to a relevant corporate partner to make everything use the status codes and not the texts. The stock handling code was unified and moved to the database triggers to be maintainable. This I consider the most pressing problem that was fixed. But it was too late, unfortunately, and with all the proper code the solution still seemed crutchy at most.