Merch38 - a B2B branded merch printing platform.

We had to work on designing a structure of entities to provide the platform with the flexibility necessary to solve this challenge. This entity structure provided us with the ability to build a UI that allows us to design almost any previously unknown type of merch and customize artwork placement in any available print area.

As a result, we received a reasonably flexible editor. Our new type of merch, which turned out to be bags, was added precisely like this.

However, it was almost impossible to think through every possible scenario and reach 100% flexibility. For example, when you put artwork on a hoodie, the artwork should have folds repeating the material, and the laces should lie on top of the wrinkled artwork. And if you print on a cup, there are no laces or folds. But if it's a bag, it may have folds but no laces. And on some other forms, you must add highlights to give the picture realism.

To solve this part of the problem while maintaining flexibility but without changing the platform code, we implemented a configuration system for different types of merch. Through this config system, it was possible to flexibly manage the sandwich of all layers of the preview generation and make the new type of merch, together with the artwork superimposed on it, so folds/shadows/highlights, etc., would look quite realistic.

The solution to this problem was to choose the correct technologies and libraries. We used node-canvas, which allows you to work with Canvas on the server.

To create photorealistic images, we used several layers of images, including the merch itself, the merch’s shadows, the artwork, and several translucent layers to create the photorealistic effect of the final image (and the laces on the hoodie).

It turned out pretty realistic.

We wanted to create an easily integrated widget with a friendly and flexible interface.

We put ourselves in the client's shoes and asked what interface would be most convenient and understandable but simultaneously flexible enough.

Having described this interface, we began to build the widget itself. In the process, it turned out that this was the right decision, as the combination of simplicity and flexibility requires hiding complex things "under the hood." And that's what we did.

As a result, we received a widget that:

• Has a simple and intuitive interface;

• Does not require developer skills and a lot of effort for integration;

• Has sufficient flexibility to customize both the set of widget elements and their appearance;

• Has several options for use. You can choose from an option with only a preview with predefined parameters or a full-featured option, where, for example, for a T-shirt, you could choose color, size, and type of collar.

This task wasn't technically complex and didn't require any non-trivial solutions. Instead, this is a perfect example of when custom web development is a must-have.

It’s a particular case with its own unique rules and nuances, of which there were many, and all of them had to be taken into account and satisfied.

Here, we used our strength - the ability to design and make very custom things user-friendly.

We used Stripe integration to accept payments. Everything else was ultra custom-made, consistently designed first, and then implemented.

We decided to become our first clients. To do this, we created two showcases using our platform, immediately finding their customers worldwide. The two cases are Gitmerch and PrintYourTweet.

Here, we had to take the side of our B2B clients and integrate our widget into both websites.

This was an excellent idea. In the process, we revealed shortcomings that were only possible to uncover by going through the entire path on our own.

As a result, we:

• Improved the widget’s interface;
• Added the ability to change the artwork on the go dynamically;
• Tested the widget and the entire platform in battle;
• Received the first profit from sales.

We generated the image on the frontend side to optimize the user's waiting time.

As a bonus, this took the load off the servers. Now the server generated a preview only once - when the user had already played enough with switching colors, sizes, collar options, etc., made their choice, and went to checkout. All other intermediate variations were generated only on the frontend side.

To make this work, we needed to remake the image generator so that the same code would work equally on the server side and on the front end with guaranteed identical results. This made the task even more difficult, but we successfully completed it using the appropriate libraries.

This task helped optimize the use of storage - images not required by the user were not saved on the server.

In the end, we additionally applied caching of the generated merch previews based on the generation input parameters. For example, if a preview of a black T-shirt with a specific collar and print had already been generated previously by another user when a new user selected the same T-shirt, we used the ready-made preview rather than generating exactly the same thing and saving a duplicate on the server.

As a result, we received an acceptable speed for receiving previews, the widget became pleasantly interactive, and storage costs were reduced by more than hundreds of times.

The solution was to teach our generative library to accept the artwork parameter as a dynamic parameter as a reactive dependency.

Fortunately, we foresaw such a turn and provided for it in the architecture of the generator. As a bonus, almost all generation parameters can be easily made dynamic.