Four Summits of Toubkal


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.

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


Before I wrote a line of software, I designed factories.

At DAHER I worked on the layout of a 14,000 m² aeronautics plant. Not on paper — in virtual reality, with full 3D simulation. We put on headsets and walked the production lines before the ground was broken. We watched parts move between stations. We found the aisle that was too narrow for the transport we had specified, and the workstation where an operator would have been reaching across a moving line every ninety seconds.

All of it before a single wall went up.

### The technology was not the interesting part

VR was the novelty, and the novelty wore off in about a week. What did not wear off was what it did to the meetings.

Before, a layout review was a group of experienced people arguing over a 2D drawing. The production manager had one picture in his head. The safety officer had a different one. The industrial engineer had a third. Everyone was fluent in reading plans, and everyone was still reading a slightly different building.

After, we were all standing in the same room. Not metaphorically — the same simulated room, at the same scale, looking at the same aisle. The argument stopped being about whose mental model was right and started being about what to do. That is a categorically different conversation, and it is faster by an order of magnitude.

The value was not visualization. The value was **shared reference**.

### The same problem, in a completely different industry

Years later I was looking at eCommerce product pages for configurable goods — modular furniture, industrial profiles, custom uniforms — and it was the same failure in a different costume.

A customer wants a sofa in a specific fabric, in a specific configuration, for a specific wall. The website offers eight swatch thumbnails and a photo of a different sofa. The customer builds a picture in their head. The manufacturer has a different picture. Nobody finds out they disagreed until the thing arrives in a box.

That gap has a name in retail: returns. In B2B it shows up as quote revisions, sample rounds, and deals that quietly stall because the buyer is not confident enough to sign.

I had spent years watching that exact gap get closed on a factory floor. It seemed obvious that the same tooling belonged on the buying side.

That is why I founded Konfigear in 2014.

### What actually transfers

Not everything from industrial simulation is useful in commerce. Three things are.

**Scale and constraint have to be real.** A factory simulation that ignores turning radii is worse than no simulation, because it produces confident wrong answers. The same is true of a product configurator that lets a customer build something the factory cannot make. If the tool permits an impossible configuration, you have not removed uncertainty — you have moved it downstream to the person who has to phone the customer back. Rule-based configuration is not a feature. It is the difference between a demo and a system.

**Fidelity matters exactly as much as the decision requires.** We did not photorealistically render that plant. We did not need to. We needed accurate geometry and accurate distances. Commerce is the opposite — a buyer choosing a fabric needs the colour to be right far more than they need the polygon count to be high. Pantone accuracy beats ray tracing. Knowing which kind of fidelity your decision actually depends on saves an enormous amount of work.

**The output has to be usable downstream.** The plant model was not a picture. It fed real planning. A configurator that produces a pretty preview and then hands production a screenshot has solved the easy half of the problem. What the customer approved has to become what manufacturing receives, automatically, or you have just added a step.

That last one took us the longest to get right, and it is the one customers care about most.

### Where this ends up

Twelve years on, the platform runs for more than 200 organizations across 20-plus countries — industrial profile systems, solar mounting, furniture, medical equipment, and, through Konfiwear, custom apparel.

The products could not be less alike. The underlying problem is identical every time: somebody is about to commit to something that does not exist yet, and they cannot picture it well enough to be sure.

Buyers do not usually walk away from configurable products because of price. They walk away because they cannot picture what will actually arrive, and the cost of being wrong feels higher than the cost of doing nothing.

Removing that uncertainty before the order is placed is the entire job. It was the job on the factory floor too. I just did not realise at the time that I was learning it.


Before I wrote software, I laid out an aeronautics plant in virtual reality. The most valuable thing it produced was not a better factory — it was better arguments.

Archive

2026