Pimcore is a framework as much as an application. Your data model, the admin interface, the API: all of it can be shaped to your business instead of the other way around. An engineer would bill days for the ten customizations below; your vibe-code agent can do most of them in one sitting, showing its work in the chat. Here is what to ask for.

1. Design your product class properly

Everything in the PIM hangs off the class definition, so getting it right matters more than anything else. Field types, which fields are mandatory or unique, and how variants inherit from parents are decisions that are painful to reverse later. Try: “Design a Product class for furniture: localized name and description, a many-to-many asset gallery, EAN marked unique, price as a quantity value with currency, and variants that inherit from the parent.” The agent writes the class definition file, loads it, and creates two test products so you can see inheritance working before you commit.

2. Build a classification store for category attributes

A TV and a T-shirt need completely different attributes, and dumping all of them into one class makes the edit screen unusable. The classification store keeps attribute groups and collections in their own structure, so each product only shows the groups its category needs. Try: “Create a classification store with an ‘Electrical specs’ group (voltage, wattage, plug type) and a ‘Textile specs’ group (material, GSM, fit), and attach the right group per product category.” The store is versioned independently of the class, so adding a new attribute group later does not require touching the product class at all. Your merchandisers stop scrolling past forty irrelevant fields.

3. Add object bricks and field collections

Some attribute groups belong to many classes but only to some products: SEO fields, energy labels, shipping constraints. Object bricks attach as a self-contained block you can add per object; field collections handle repeating rows like spec-sheet lines. Try: “Build an SEO brick with meta title, description, and canonical fields that I can attach to any product class, plus a field collection for spec-sheet rows with name, value, and unit.” Reusable blocks mean you define each group once instead of re-modeling it per class.

4. Shape the admin for each role

The default admin shows everything to everyone, which is exactly wrong for a merchandiser who needs five columns and two menus. Pimcore perspectives and saved grid views let you give each role a focused workspace. Try: “Make a ‘Merchandiser’ perspective that shows only Products and Assets, with a saved grid view of image, EAN, price, and status, and no Settings menu.” Fewer wrong clicks, less training, and fewer accidental config changes by people who meant to edit a price.

5. Define thumbnail strategies per channel

Every output channel wants different renditions: a shop listing, a zoom view, a PDF cover, a newsletter. Thumbnail definitions are configuration, and a well-designed set is the difference between sharp pages and mush. Try: “Create three thumbnails for our shop: listing at 800px cover-cropped, detail at 2400px with cover and center, both output as WebP, plus a pdf-cover image for datasheets, then warm the cache for the catalog root.” Art direction encoded once, applied to ten thousand assets automatically, with editors able to set focal points where the crop should favor the subject.

6. Set up the asset metadata schema

Assets without metadata are liabilities: you cannot prove you had the rights, and your storefront cannot print alt text. Predefined metadata in Pimcore defines the fields; the trick is populating the backlog so the new rule is not an empty form. Try: “Set up predefined metadata for copyright holder, license, alt text, and usage expiry, then backfill them from the folder structure wherever the folder name implies the brand.” The agent fills what it can infer and hands you a shortlist of assets where a human has to decide.

7. Carve up roles and workspaces

Agencies, photographers, and translators all need in, but nobody needs everything. Pimcore users and roles combined with workspace permissions control exactly which folders each login sees in objects, assets, and documents. Try: “Create an ‘Agency’ role that can upload and edit assets only under /Brands/Acme and products only under /Catalog/Acme, read-only everywhere else, and no delete.” You stop being the person who restores files after an overeager freelancer tidies up.

8. Build custom reports and pin them to the dashboard

Pimcore’s custom reports run straight SQL or PHP against your data, and the good ones answer the questions you ask weekly. Products missing images, duplicate EANs, translation coverage per language: all are a query once someone writes it. Try: “Build me custom reports for products missing an image, duplicate EANs, and translation coverage per language, and pin all three to the admin dashboard.” The next status meeting runs off the dashboard instead of someone assembling numbers by hand.

9. Harden the Data Hub API endpoint

Opening a GraphQL endpoint to the outside world is a security decision, not a checkbox. The agent can configure API key authentication, restrict the workspace to the exact object tree the integration needs, and expose only selected fields. Try: “Lock down the Data Hub endpoint: API key auth, only the /Catalog/Shop subtree readable, and add a marginPercent field computed from cost and price that only the shop can query.” A scoped endpoint means a leak in one integration never becomes a leak of everything. After any change, the agent regenerates the GraphQL schema and re-runs your test query to prove the response shape did not drift.

10. Production hardening pass

The last ten percent before real use is unglamorous: debug mode off, a working mailer so workflow emails actually send, backups that exist and restore, maintenance jobs on cron. The agent can audit the whole stack and fix what it finds. Try: “Audit my install for production: debug off, mailer configured and tested with a real email, nightly database and var/ backup with a restore drill, and the maintenance cron set.” Ask it to write down the restore steps it used. The drill you run once is the difference between a bad evening and a bad week.

Start with the data model, because everything else sits on it. Then let the agent harden, scope, and polish while you get on with the catalog. Your server is on Pimcore on OpenSysLab.