Made-to-order, with the customer’s approval before anything is produced.
Selling something you make for one person does not fit a normal product page. The customer has to send you a photo, you have to build the thing, and they have to see it and say yes before you spend the material. MevvAtelier is that pipeline inside WooCommerce: a configurator that prices the order on the server, a vault the uploaded photos never leave, a signed link the customer opens without an account to approve the preview or ask for a change, four order states that only move in one direction, and a queue screen that tells your workshop what is late. The photos are private files with their own retention clock, not media-library attachments, because a customer’s photograph is not a picture of a product.
All prices include VAT.
1 USD = 49,0562 ₺ (İşbank rate)
What it does
Each capability exists to remove a specific operational friction.
The configurator shows a total as the customer chooses, but the number the order is written with is calculated again on the server from the selection alone. A total posted by the browser is ignored outright. Money is held as whole minor units, so a long order never drifts by a cent between the invoice and the order.
They go to a directory whose name cannot be guessed, protected four ways at once — an .htaccess rule, a web.config for IIS, an index.php, and file permissions that let nothing but the site read them. A file is accepted for what its bytes are, not what its name claims: an executable renamed to .jpg is refused at the door. They are never given a public URL.
Every photo and every preview is served through a single gateway. Your team is let through by their WooCommerce order permission; the customer is let through by a signed link that is checked against that order and no other. A link built for one order cannot open another order’s file, and a tampered link opens nothing.
The approval page opens straight from the email — no login, no password, no cart. Asking someone to register before they can look at their own preview is the surest way to lose the approval. The link carries its own authority, is signed, and expires; the page is never cached, so one customer’s preview cannot be served to anyone else.
Before approval the customer can ask for a correction as many times as it takes, and each request is recorded against the order. After approval the revision form disappears — and the server refuses the request too, not just the screen. Under Turkish distance-selling rules a personalised item carries no right of withdrawal once it is made, so the moment the customer agrees to that is written down with the approval.
Modelling, awaiting approval, printing, done. What may follow what is written as a list of permitted moves, not a list of forbidden ones: a step nobody thought of is refused by default rather than quietly allowed. The states are real WooCommerce order statuses, so they appear in the order list, in reports and in your existing filters.
The workshop screen sorts open orders by how long they have been waiting and marks the ones past their promised time in red — twenty-four hours normally, six on a rush order. The operator uploads the preview from the same screen and the customer is emailed in the same action; there is no second place to remember to click.
Order received, preview ready, approval recorded, shipped. They are drawn through your store’s own email template, so they look like the rest of your mail rather than something bolted on. The approval link appears twice in the message, as a button and as plain text, because some mail clients will not render the button.
A daily job deletes the uploads and previews of finished orders after a retention period you set — sixty days out of the box. The order, its price and its approval record stay; the customer’s photograph does not. Keeping a child’s photograph on a shop server indefinitely is a liability, not a feature.
The configurator and the approval page both switch page caching off for themselves, in the language LiteSpeed, WP Rocket and W3 Total Cache all understand, and send no-store headers besides. A cached configurator submits with a stale token and fails silently; a cached approval page shows one customer’s preview to the next visitor. Neither can happen here.
Product information