Drift is invisible until it costs money.
A GTIN corrected on the shop and not on the marketplace is a suppressed listing three weeks later — and nothing tells you in between.
In development · founding partners onboarding from Q4 2026
Product Master
One product record. Every channel’s version of it, generated — not retyped.
A product information management core built for sellers who list the same catalogue on their own shop, on marketplaces in several countries and to B2B customers — and who are tired of maintaining it four times.
Builtlocal build · synthetic data
What a product master actually is
A product master is the single canonical record for each product: identity, variants, identifiers, attributes and media. Every channel — your shop, amazon.de, Kaufland, a Mirakl operator, a B2B price list — needs a different projection of that record: different required fields, a different title length, different units, a different language.
Without a master, each projection is maintained by hand, and they drift. With one, projections are generated and checked.
Why it matters
Three ways a catalogue goes wrong quietly.
Compliance is now product data.
EPR registration numbers, the GPSR responsible person, CN codes: they attach to variants and they vary by market. A spreadsheet cannot hold that safely.
Every new channel is a new copy.
Unless it is a projection. The fourth channel is where maintaining four versions by hand stops being a nuisance and starts being the job.
How it works
Four parts, and each one carries its own state.
Identity and variants
BuiltOne master, N variants. GTIN, EAN, SKU and MPN live on the variant, and identifier history is kept append-only — so a corrected identifier is a new fact rather than a lost one.
Attributes per locale
BuiltThe same attribute, authored per language. Channel-scoped values are in development; market-scoped compliance facts are planned, and they live in their own tables with validity windows rather than as attribute values. That separation is deliberate: a legal fact has a date range and an authority, and an attribute does not.
Channel dialects
BuiltMapping rules per channel generate that channel's version: title format, taxonomy node, unit conversion, truncation. Generated and replayable — never stored as a second truth to maintain.
Validation
BuiltRequired fields, formats and identifier uniqueness are checked on save. The per-channel rules that decide whether a listing may be submitted are the Channel Readiness module.
Product master → channel dialectsSynthetic data
Product masterSKU CFT-6C-INOXGTIN 8412345678904
- Shop · es-ESCafetera italiana de acero inoxidable, 6 tazasmaterialacero inoxidable 18/1046 / 255
- Amazon · de-DEEspressokocher Edelstahl 6 Tassen — induktionsgeeignetbullet_point_1Induktionsgeeignet, spülmaschinenfest55 / 200
- Marketplace · ro-ROEspressor manual din oțel inoxidabil, 6 ceșticaracteristicicompatibil inducție45 / 120
One record, N versions
The channel versions are generated, not maintained.
The data model
What is actually stored
- product_master
- the canonical record
- product_variant
- what is actually sold
- identifier
- GTIN, EAN, SKU, MPN — with history
- attribute_definition
- typed, versioned
- attribute_value
- per locale; per channel scope in development
- measurement_unit
- canonical, with an authored override
- category_mapping
- taxonomy node per channel
- media_reference
- images and documents, by reference
- compliance_fact
- EPR, responsible person, CN code — planned, separate tables with validity windows
Versus the alternatives
You already have options, and one of them is free.
| Spreadsheet | Shop admin | Feed tool | Enterprise PIM | TOVIA | |
|---|---|---|---|---|---|
| One canonical record | no | per shop | no | yes | yes |
| Per-locale attributes | manual | per shop | no | yes | yes |
| Channel projections generated | no | no | feeds only | yes | yes |
| Readiness checks before submission | no | no | partial | partial | yes — see Channel Readiness |
| EU compliance facts per market | no | no | no | rarely | in development |
| Joined to stock and orders | no | partial | no | no | yes, on the local runtime |
| Set-up for a 5,000-SKU catalogue | days, then forever | — | hours | months | import contract, in development |
Who uses it
Three jobs this changes.
Catalogue / PIM manager
Owns the truth about every product, and is the person who finds the drift.
Today that means comparing exports and fixing the same attribute in three places. With a master, it means fixing it once and watching the projections regenerate.
Marketplace manager
Lives in rejection reports and in each marketplace’s own vocabulary.
The rules of amazon.de and Kaufland are different, and neither is the shop’s. Channel dialects put those differences in the system instead of in one person’s head.
Head of ecommerce operations
Answers for the numbers, and for what the company promised a customer.
Needs to know that a listing is legal in the market it is sold in, and that stock said to exist does. That is why the master is joined to readiness and to availability rather than sitting beside them.
Implementation
How you would actually start.
- 01Export from wherever the catalogue lives today — shop admin, spreadsheet, an existing PIM.
- 02Import with staging and preview, so you see what would change before anything changes (in development).
- 03Identifiers and attributes are validated: check digits, uniqueness, required fields per type.
- 04Channel mappings are configured — one rule set per channel, per locale.
- 05Readiness checks run before the first submission, so the first thing the marketplace sees is a listing that passes.
FAQ
Questions people actually ask
Do I need a PIM under 500 SKUs?
Probably not, and we would rather say so. On one or two channels in one country, a spreadsheet and a careful person still work. The maths changes at roughly 500 SKUs on more than two channels in more than one country — that is where maintaining four versions by hand starts costing more than the software.
Does it handle variants and bundles?
Variants, yes — they are first-class, and identifiers live on the variant rather than the product. Bundles are planned; they are a pricing and stock question as much as a catalogue one, and doing them badly breaks availability.
Which languages does it support?
Any locale. The product is authored per locale rather than translated from one master language, because a marketplace title in German is not a translation of the Spanish one — it is a different field with a different limit.
Can it import from Akeneo, Plytix or Excel?
Excel and CSV through the import contract, which is in development and published in full. Migrations from another PIM are planned; they are a mapping exercise on top of the same contract.
Is my data exportable?
Yes — a full, machine-readable export of your tenant. The EU Data Act obliges us to make switching possible, and we would rather be the vendor you could leave than the one you cannot.
What does “built, synthetic” mean?
It runs today on a local build against synthetic data. There is no production deployment and no customer data in it. Where a capability is not built, this site says in development or planned instead — those words are load-bearing here.
What changes for you
What a master record changes about your week.
A new marketplace is a new projection and a rule set, not a new copy of the catalogue for somebody to keep in step.
Catalogue / PIM manager
BuiltChannel dialects and field mapping
A correction is made once, in the place the business considers true, and every channel's version follows from it.
Whoever finds the mistake
BuiltProduct master with variants and identifiers
When a second country describes your products differently, you change the attribute for that market rather than forking the record.
Compliance or operations lead
In developmentAttributes per locale and per channel scope
Bring a real catalogue.
An export, not screenshots. Founding partners see their own products in the product master first.