
Mechanical engineer turned software founder. I started out designing aerospace manufacturing facilities in VR at DAHER, then founded Konfigear in 2014 to bring the same visualization tools to the way configurable products are sold. Today the platform serves more than 200 organizations across 20+ countries, and Konfiwear applies it specifically to custom apparel.


Linkedin

Twitter

Founder & CEO, Konfigear and Konfiwear

Yassine Ait Oufkir


Here is a workflow I have watched in some version at nearly every custom apparel business I have visited.

A club wants twenty jerseys. Someone in sales mocks up a design — often in Illustrator, sometimes in a web tool, occasionally in PowerPoint. It goes to the customer as a flat image. The customer says the blue is wrong. Round two. The customer says the sponsor logo should be higher. Round three. Eventually: approved.

Then the approved file goes to production, and somebody spends the next hour rebuilding it.

Not adjusting it. **Rebuilding it.** Correct colour profile, correct separations, correct placement on the actual pattern pieces, correct sizing per garment size, names and numbers laid out from a roster that arrived as a spreadsheet with inconsistent capitalisation.

That hour is the real cost of a custom order, and almost nobody prices it in.

### Why the mockup and the print file are different objects

The mockup exists to close the sale. It is optimised for looking convincing on a screen. It does not need to know that the garment is cut from six pattern pieces, that the sublimation transfer needs bleed past the seam allowance, or that the customer's RGB blue does not exist in the ink set you are running.

The print file exists to drive a machine. It has to know all of those things.

They are made by different people, in different software, for different purposes. So the handoff between them is manual by construction — and manual handoffs are where errors enter.

The errors are not evenly distributed either. Most of them are invisible until the press runs:

- A logo that looked crisp at screen resolution is 90 DPI when scaled to actual chest width
- A colour approved on a customer's uncalibrated laptop is two shades off the club's brand blue
- A design placed near a seam that shifts when the panel is cut
- A roster where "MCDONALD" and "McDonald" are two different players

You find these on press, on the garment, after you have consumed material and machine time. Then you eat the reprint, or you ship it and eat the complaint.

### The usual fixes, and why they only half work

**Hire better prepress people.** This works, and it is expensive, and it does not scale. Your throughput is now capped by how many skilled operators you can hire in your city. It also means your best technical people spend their day on repetitive rebuilds instead of the genuinely hard jobs.

**Lock down the templates.** Restrict customers to a few fixed layouts. This reduces errors and it reduces orders, because the reason people buy custom is that they want something specific. You have solved a production problem by making the product worse.

**Add approval steps.** More sign-offs catch more errors, and every sign-off adds a day. In teamwear, where the order has to arrive before the season starts, added days lose deals outright.

Each of these treats the symptom. The disease is that the file the customer approved is not the file that goes to production.

### Closing the gap instead of managing it

The alternative is to make the customer's design *be* the production file — same object, two views.

That means the customer designs on the real garment: actual pattern geometry, actual print areas, actual constraints. Colours are constrained to what you can genuinely produce, so an approved colour is a producible colour. Logo placement is validated against seams and safe zones as the customer moves it. Minimum resolution is enforced at upload, not discovered at output. Rosters are structured data, not a pasted spreadsheet.

Then the order produces the print-ready output automatically — separations, bleed, per-size scaling, correct profile for DTG, sublimation, screen print or embroidery.

This is what we built Konfiwear to do, so I am obviously not a neutral party. But the principle stands regardless of whose software you use: **if a customer can approve something you cannot produce, your workflow has a manual repair step in it, and you are paying for that step on every single order.**

### What it changes

The hour of rebuild goes away. That is the obvious one, and it is not the important one.

The important one is what happens to the front of the process. When the customer is looking at their actual garment rather than an approximation, the approval rounds collapse — usually to one. The uncertainty that caused round two and round three was never really about the design. It was the customer not trusting that what they saw was what they would get.

Custom apparel buyers do not abandon orders because of price. They abandon because they are not sure, and the cost of a wrong order of 200 jerseys is high enough that not-sure means not-yet.

Remove the doubt at the point of design, and you get the production saving as a side effect.

### A question worth asking your own team

Not "how do we make prepress faster?" but:

*How many hours a week does this business spend converting files a customer already approved into files a machine can actually run — and what would we do with those hours instead?*

Most operations I ask have never counted it. The number is usually larger than they expect.


Your customer approved a flat mockup. Your production team received something they have to rebuild by hand. That gap is where the margin goes.

Web To Print

The Expensive Part of Custom Apparel Isn't Design. It's Prepress.