Vowly Store: selling handmade wedding stationery across Europe

Vowly Store sells wedding invitations that are made by hand — dried flowers, kraft paper, a hand-tied bow — along with menu cards and henna cards, personalised with the couple's names, date and wording, and shipped across Europe. Invitations sit between €74 and €94, posters at €14.95, with free EU shipping over €59.

Those are the facts a visitor sees. Underneath them is a category of commerce that behaves almost nothing like ordinary retail, and the engineering has to reflect that.

Made-to-order breaks the retail assumptions

A normal store has inventory. It knows it has 40 units, it decrements on purchase, and it ships from a shelf. A made-to-order store has none of that. Nothing exists until the order is placed, which quietly invalidates a long list of defaults:

• Stock counts are meaningless. Capacity — how many pieces the workshop can finish this week — is the real constraint, and no e-commerce platform models it out of the box.
• "Order placed" is not the start of fulfilment. Proof approval is. The clock a customer cares about starts when they sign off on the design.
• Cancellations and returns work differently. A personalised piece cannot go back on a shelf, which changes both the policy and the refund logic.
• Delivery estimates are a function of the workshop queue, not of a courier's transit time alone.

The proofing loop is the critical path

Vowly Store sends a digital proof and waits for approval before printing. That single step is where most of the operational risk lives, because it is the only point at which a customer can catch a misspelled name before it is printed onto ninety cards.

Treated as an afterthought, proofing becomes an email thread — untracked, unsearchable, and impossible to report on. Treated as a first-class object, it becomes a state machine with a small number of well-defined transitions:

1. 1.Order received, personalisation captured.
2. 2.Proof generated and sent.
3. 3.Customer approves, or requests a change with a specific comment.
4. 4.Revision issued — with a hard cap on rounds, because unbounded revisions destroy margin.
5. 5.Approved, locked, released to production.

Once it is a state machine you can measure it. How long does a proof sit unapproved? Which designs generate the most revision requests? That last question usually reveals a template problem, not a customer problem — a field that is too small for long names, or a font that renders a diacritic badly.

Any language, which means any character set

Vowly Store accepts invitation wording in any language. This is a genuinely non-trivial commitment for a print product. Turkish dotted and dotless i, German umlauts, French accents and Arabic script all have to survive the journey from a web form, through storage, into a layout engine, and onto paper. Every hop is a place where an encoding assumption can quietly corrupt a name.

The defence is unglamorous: UTF-8 end to end with no exceptions, fonts chosen for coverage rather than for looks alone, and a proof step that renders with the real production pipeline rather than a preview approximation. If the proof is generated by different code than the print file, the proof is not a proof.

Cross-border delivery is a pricing problem

A free-shipping threshold — €59 here — is a deceptively deep feature. It has to be evaluated against the right subtotal, in the right currency, after discounts but before or after tax depending on the jurisdiction, and it has to be shown in the cart early enough to actually change behaviour. Country-specific rates below the threshold multiply the cases.

The practical advice is to keep this logic in one place and test it as a pure function over a table of cases, rather than letting shipping rules accrete across a theme, an app and a checkout script. We wrote more about the surrounding problem in our note on localising a European store.

Why Shopify, and where it stops

Vowly Store runs on Shopify, and for a store of this shape that is the right call. Checkout, payments, tax and fraud handling are solved problems that no small team should rebuild. What the platform does not solve is everything specific to made-to-order: the proofing loop, workshop capacity, personalisation capture with validation, and print-ready file generation.

The architecture that works is a boring one. Let the platform own the transaction. Build the domain-specific workflow alongside it, connected by webhooks, and keep a clear boundary between the two so that a platform change does not ripple into the workshop.