YUXI: a wholesale B2B e-shop for Asian restaurants, in six languages

YUXI s. r. o.

2026-09-07

YUXI is a Bratislava wholesaler supplying Asian restaurants and sushi bars — takeaway packaging, sauces, rice, seaweed, consumables. Stock comes from a supplier in Vienna, sells by the carton, and is paid against an invoice. The brief arrived as a PDF price list: 202 rows, in English and Chinese only, without a single Slovak word. Yet the buyer is a head chef or an owner in Bratislava who often does not speak Slovak — and just as often does not speak English either. We built an e-shop that speaks six languages all the way into the address bar, takes orders by the carton with no account and no card payment, fills its billing block from the company register once a tax ID is typed, and posts the finished order into SuperFaktúra. Every product stands as a background-free cut-out on a colour field — the only treatment that turns photographs shot on five different surfaces into one coherent catalogue. The client has run the catalogue himself in Sanity Studio ever since. Delivered in 10 working days for €650.

B2B e-shop + CMS catalogue

Project type

Carton orders from restaurants that buy in six different languages

Main goal

€650

Project price

View live website

Selected screens from the finished site

Visual project preview shows how the website looks on different devices. Responsive design ensures perfect display on mobiles, tablets and desktops.

The hero on the indigo field: a product cut-out, poster typography, and the phone number right below it.

Six things that made this shop demanding

A food-service wholesaler resembles an ordinary e-shop in nothing that matters: a different purchase unit, a different payment, a different document, and a buyer who reads in a language the seller does not. These are the differences, and how we handled them.

Problem #1

A kitchen that buys in six languages

Asian kitchens in Bratislava are run by Vietnamese, Chinese, and Ukrainian owners; the stock comes from a German-speaking supplier in Vienna, and the invoicing is Slovak.

Our solution

The site runs in six languages, and the page address is localized too — a German buyer reads /de/ueber-uns, a Vietnamese one /vi/ve-chung-toi. The root always resolves to Slovak rather than to the browser setting: an owner with a Vietnamese phone is buying for a Slovak company.

Technologies and implementation

A custom i18n layer + a proxy with permanent redirects

1
Problem #2

A 202-row price list without one Slovak word

The source document had only an English and a Chinese column, article numbers repeated inside it, and eight items had no English name at all.

Our solution

We moved the catalogue into Sanity as 202 documents, each name holding six language fields. Brand names — Yamasa, Kikkoman, Sriracha, Sambal Oelek — are never translated; the product type is. The key is the item identifier, not the article number, which is not unique in the source.

Technologies and implementation

Sanity CMS + a migration script + schema-driven type generation

2
Problem #3

A restaurant does not buy a piece, it buys a carton

One carton is typically 500 or 600 pieces, and prices are compared in cents per piece. An ordinary per-piece cart would produce unusable numbers in this trade.

Our solution

Quantity is entered in cartons everywhere, with the per-piece figure sitting beside the price. The cart is a drawer of product cut-outs that stay recognisable at 48 pixels, and payment is by invoice or cash on delivery — card payment makes no sense here, and the form says so plainly.

Technologies and implementation

A Zustand cart + unit maths resolved on the server

3
Problem #4

A company purchase needs billing data, not an email address

Without an exact company name, seat, and registration number, an order cannot be invoiced, and the manager has to chase it by phone. Austrian companies, meanwhile, have no such number at all.

Our solution

The buyer types a company or VAT number and the name and address arrive on their own. VAT numbers go through VIES, which covers every EU jurisdiction; company numbers go through the Slovak and Czech registers — which is how an Austrian buyer can finish the form at all. The module never throws: when a register is down, the form behaves exactly as it did before autofill existed.

Technologies and implementation

VIES + RPO / ARES, cached, with a safe fallback to manual entry

4
Problem #5

An order must not fall between the website and the bookkeeping

The company invoices through SuperFaktúra. Retyping lines from an email into a document is extra work, and it is exactly where an article number gets mistyped.

Our solution

A submitted order goes out by email and simultaneously creates a SuperFaktúra document with every line, article number, and carton count. If every line carries a price, the document is a real invoice for the buyer; if even one line does not, it becomes a received order for the manager to finish. A document that would quietly bill less than the goods cost must never be issued here.

Technologies and implementation

SuperFaktúra API + Resend + a pricing regression test in CI

5
Problem #6

The range changes weekly, and the client has to run it himself

Three batches of the client’s own product photographs arrived within three weeks, and new items came with them. The last one carried a single sentence: „dajte fotky do galérie a pridajte slnečnicový olej, tašku a šalátový box.“

Our solution

Everything that moves — products, prices, photographs, galleries, contacts, even the VAT-payer status — is a Sanity document the client edits in his own Studio. Uploaded photographs are matched by checksum, so the same frame is never stored twice. A photograph that would have to be assigned by guesswork is not assigned at all: a wrong picture on a food item is a claim about goods the customer is paying for.

Technologies and implementation

Sanity Studio + webhook revalidation + idempotent scripts

6

Similar problems in your business? We will help you solve them with modern tech stack.

Final structure

Complete web structure designed for maximum conversion and user experience. Each page has clear purpose and optimized navigation.

Home
Catalogue
Department (×6)
Product page
Order form
About
Contact

Most important website sections

Each section solved specific business problem and increased conversions

1

Hero and six departments

The first screen states what the company sells and how it is bought — by the carton, on invoice or cash on delivery — with the phone number directly underneath. Then a grid of six departments, each carrying its own colour field and a single product cut-out.

2

A catalogue with filters and two views

Department, availability, sorting, and search by name or article number. The Cards / Table toggle exists because a buyer reordering the same items every week reads rows faster than tiles.

3

A product page measured in cartons

Article number, size, pieces per carton, availability, and the price per carton alongside the per-piece figure. Quantity is entered in cartons, with the piece count spelled out below the field. Where a price is not known yet, the item says so and offers an enquiry instead of a silent zero.

4

An order form that fills itself from the register

The form opens with a company or VAT number field. Once it is typed, the company name and address arrive from public registers, leaving contact, collection method, and payment. Manual entry stays one click away — a register must never block an order.

5

A Sanity Studio in six languages

Products, departments, prices, photo galleries, contacts, and even the VAT-payer status are CMS documents. Every name has six language fields, and a change is live within a minute thanks to webhook revalidation.

6

About and contact

Registration data, year of incorporation, the director’s name, and the six departments with a note on who each one serves. Contact routes to phone, WhatsApp, and Telegram — the channels the company actually answers on.

Project stack

Frontend

A catalogue interface for a buyer who orders fast and often — filters, search by article number, and a drawer cart.

Server componentsClient-side cartOrdering by the carton
TypeScript
React 19
Next.js 16
Tailwind CSS v4
Zustand
Motion
Lenis

Content and languages

Six languages, including localized URL segments and hreflang on every page. The catalogue, prices, and photographs are Sanity documents the client edits himself.

6 languages: sk · de · en · uk · vi · zhLocalized page addressesCMS-driven catalogue
Sanity CMS
next-sanity
Sanity Studio
i18n (6 languages)
hreflang + x-default

Orders and invoicing

Company lookup from public registers, VAT resolved from a CMS setting, a notification email, and an automatically created document.

Autofill by company or VAT numberA document in SuperFaktúraPayment on invoice or COD
VIES
RPO / ARES
SuperFaktura API
Resend

Deployment and checks

GitLab CI deploys both the site and the hosted Studio, and every build runs regression checks on prices, carton maths, and VAT status.

CI/CDPricing regression testsWebhook content revalidation
Vercel
GitLab CI/CD
Sanity webhooks

💡 Modern tech stack = fast website + easy maintenance + long-term support

Delivery process

The project ran from 19 August to 7 September 2026, across ten working days. The client set the order of the phases: first we needed the catalogue, then his photographs, then his prices — and German arrived as a separate request after handover.

19–24 Aug

Art direction, catalogue, and the shell of the shop

3 days

We settled on the cut-out motif and the three-colour palette, extracted 202 items with their photographs from the client’s PDF, and built the catalogue, product page, cart, and order form. The Ukrainian version and GitLab CI deployment landed here too.

25–27 Aug

CMS, company register, and invoicing

3 days

The catalogue moved into Sanity, the form learned to fill a company from its registration number and later from a VAT number across the EU, and orders began creating SuperFaktúra documents. The client sent 55 of his own photographs — 20 replaced the PDF cut-outs. Page addresses became localized.

31 Aug – 1 Sep

Prices, gallery, and the automatic invoice

2 days

The client confirmed the price list and his VAT status, so prices went live — per carton and per piece — and the status became a CMS toggle. A product photo gallery arrived, and a fully priced order began issuing its own invoice. Prices, carton maths, and VAT are guarded by a regression test in CI.

2 Sep

Contacts into the CMS, and order among the languages

1 day

Phone, email, social links, and the registered address moved into Sanity, so they change without a deploy and are live within a minute. Chinese disappeared from the interface of every other language — Chinese names belong in the Chinese version, not in a Slovak packaging description.

4–7 Sep

German as the sixth language, and more stock

1 day

German arrived as a separate request after handover: 379 interface strings, 268 German names in the CMS, its own umlaut-free URL segments, and the 1.234,50 € price format. Six abbreviations no longer fit the header, so the language switcher became a dropdown that spells every language in its own language. Three days later two new shelves and another batch of the client’s photographs joined the catalogue.

Project FAQ

Case study summary

This case study shows a specific problem, solution, and outcome. It helps you compare your project to a similar scenario.

Definition: a case study describes a real project with clear inputs and outcomes.

Need a B2B e-shop that sells by the carton and invoices itself?

We can design the catalogue, the order flow, and the invoicing hook so that every order leaves with complete company details and you run the range yourself — in as many languages as your market needs.

Leave your contact (email or phone is enough)

Write on WhatsApp

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

✨ Ordering by the carton • Company data from the register • The catalogue in your hands