Pólónagyker

Pólónagyker is one of Hungary's established promotional-textile wholesalers. Milcomp built their webshop and the system behind it, and moved the brand from its former tees.hu name to polonagyker.hu in the summer of 2026.

The challenge

A promotional-textile wholesaler is not an ordinary shop. The same t-shirt exists in many sizes and colours, and the price is not set by the product but by who is buying and how many: a retailer sees one price, a wholesaler another, and somebody ordering in bulk a third. On top of that, a large share of orders are not plain purchases at all - they are printed or embroidered with a logo, so the order carries an artwork file and a round of correspondence with it.

The previous system was a Ruby on Rails shop that could no longer serve this, and a rebrand is not solved by pointing a domain somewhere else when every product URL changes with it.

The solution

A new webshop on Laravel with a Laravel Nova admin. The catalogue is three levels deep - base product, product, product variant - with size and colour attributes, so a family of shirts is not a thousand separate products. Pricing is tiered, and the tiers are tied to stock, currency and customer type.

Logo orders have their own submission flow: the customer uploads the artwork and states the technique, the placement, the quantity and the deadline, and the uploaded files reach the admin over a protected download link. Re-orders are flagged separately, because there the artwork already exists.

A partner API and an AI assistant

Resellers do not want to click, they want to synchronise. So the shop has a partner REST API: catalogue, variants, stock, categories and brands. The important part is that every API partner has their own key, a per-minute rate limit, a language, and a pinned price tier - the partner receives over the API exactly the price their contract entitles them to, and cannot look across into another tier. Partners manage their own keys from their profile.

The site also runs an AI assistant that works only from the shop's own knowledge base: vector search over uploaded documents, with a system prompt that forbids off-topic answers and forbids inventing facts. If it does not know something, it says so rather than making it up.

Technology

Laravel and Laravel Nova, with Livewire for the interactive surfaces and a Tailwind-based front end. Multilingual content and multiple currencies, with the euro price derived from the daily central-bank rate through a three-stage fallback for when the rate service is unavailable. Transactional e-mail from MJML templates, error monitoring with Sentry, and bulk product import and export from Excel and CSV.

The rebrand that did not break

Moving from tees.hu to polonagyker.hu is hard because the old product links were alive: external sites, ads and saved bookmarks pointed at them. So we paired the old product list against the new one and put a 440-item Cloudflare Bulk Redirect in front of the edge: static pages, 427 verified product pairs, and path-level fallbacks for what could not be paired individually. The pairing was not a machine guess - it was built from slugs read out of the old shop, by exact transformation plus a manually sampled approximate match.

For the same reason the old webroot, database and CDN names stayed on the server, and the existing Jenkins job was renamed rather than replaced: the worst thing you can do during a rebrand is rename the infrastructure too, and then not know what was built where.

What to take from this

With tiered pricing the decisive question is not how you store prices, it is who is allowed to see which one - and that has to be enforced on the API exactly as it is in the shop. If a partner could request an arbitrary price field over the API, your whole pricing structure is public.

And on migration: the quality of your 301s is what decides whether a rebrand keeps its organic traffic. A blanket redirect to the homepage works formally and throws away almost everything.