.png)
Producing a B2B product catalog typically takes 3 weeks to 3 months from a finalized product list to a distributable document. Short promotional flyers and single-brand catalogs take 4 to 12 hours per document. Catalogs above 200 pages, or with thousands of SKUs, take 2 to 3 months. Each round of updates after publication adds roughly another week.
The variable that determines where a team lands in that range is not page count or SKU count. It is how much of the layout is assembled by hand.
When catalog pages are generated from a product feed against pre-approved templates instead of placed manually, the layout stage collapses from weeks to seconds. In Catalogy, a 500-product catalog generates in roughly 20 to 30 seconds, and a 6,000-product catalog takes about the same, because the work scales with the data rather than with the page count. What remains is product selection, copy, and approval, which is where catalog time should have been going all along.
Most catalog production is still page-by-page layout in a design tool. A designer receives products in a spreadsheet, images from a shared drive, prices from an ERP or a price list, then places each element manually.
Per product, that means: find it in the export, locate its image at print resolution, crop and size it, place it, type the name and description, build the spec table, check the text has not overflowed, verify the price. Then repeat. Several hundred times.
The arithmetic explains the timelines above. At a realistic 3 to 4 minutes per product, 500 products is 25 to 33 hours of placement, and that is one clean pass before any review round comes back with changes.
The cost of this approach scales linearly with the catalog. Two hundred pages is not harder than twenty pages. It is ten times as much of the same work.
Catalogy inverts the unit of work. Instead of building pages, you build a template once, then generate pages from data. You upload a product feed as a spreadsheet or CSV containing SKU, category, product name, description, price, and image URLs, map each column to the matching element in your template, and press generate. Catalogy walks the feed and lays out every product against the template automatically.
A 92-page catalog with 150 products generates in seconds. So does one with 6,000 products. Templates are designed to your branding by Catalogy's in-house design team during initial setup, and you get a built-in design studio if you want to build or adjust them yourself. Product-level and category-level templates are supported, so A-tier products can get a full page while C and D-tier products get a quarter page, without anyone laying out either by hand.
.png)
Teams routinely underestimate their own catalog cost because the hours are spread across people who have other jobs.
Catalog production almost never sits with one owner. A marketing coordinator pulls the product list. Someone in product or category management confirms the assortment. A sales ops person checks the pricing. A designer builds the pages. Someone senior reviews the proof. None of them have "catalog" in their job title, none of them log the time against a project code, and the work is treated as an interruption to their real role rather than a line item.
Two things follow from that. First, nobody can tell you what the catalog costs, so it never gets evaluated as a spend. Second, because nobody is measuring, estimates drift. A designer who says a job will take twelve hours and finishes it in four is not being dishonest. There is simply no baseline anyone can check the number against.
Try the calculation on your own team. Take the fully loaded hourly cost of everyone who touches the catalog, multiply by the hours they actually spend on it, then multiply by the number of catalog and update cycles you run per year. A mid-size distributor producing one annual catalog plus quarterly updates, with 60 hours on the build and 15 hours per update, is spending 120 hours a year on catalog production alone. At a blended internal cost of 45 dollars an hour, that is roughly 5,400 dollars of internal time that appears nowhere in the marketing budget, and it excludes the opportunity cost of what those five people were not doing instead.
If the hours are not tracked, the catalog looks cheap on paper. It is not. It is a recurring internal project with no line item.
Because generation is a single step against a known feed, catalog production stops being a diffuse pool of untracked hours spread across whoever is available. The template investment is one-time and measurable. Generation is instant. Updates are a sync. When your CFO asks what the catalog costs, you can answer with a number instead of a shrug.
The hours themselves mostly disappear. The 25 to 33 hours of placement work becomes a single generate step, and the week per update round becomes a one-click sync, which returns that time to the people who were absorbing it as an interruption to their real jobs. For most teams that is the difference between one catalog a year and a catalog per season, per region, or per key account, at no extra production cost.
And because every page is generated against a locked template rather than assembled by hand, the output is on brand by default. Your fonts, colors, logo placement, spacing, and layout rules are built into the template once, so nobody is eyeballing margins at 6pm or pulling last year's logo out of an old file. The version a country manager publishes on their own looks exactly like the one your designer built, because it came from the same template. Brand consistency stops being a review step and becomes a property of the system.
Manual layout does not just scale with page count. It scales with every version.
A manufacturer selling into Germany, France, Italy, and Poland does not produce one catalog. It produces four, and if it also runs six promotional flyers a year, that is 24 documents, not six. Each one is a separate file in a separate folder, and each one is built by hand.
The predictable result is a bottleneck at whoever owns the design file. The country manager in Poland knows the market and knows exactly which twelve products should be on the flyer, but cannot build it, because building it requires the design tool and the master file. So the request goes into a queue behind the other three markets. And when a region loses patience and edits its own copy of the file, brand consistency quietly breaks: last year's logo, an old disclaimer, a price that was corrected everywhere except there.
Two mechanisms, used together:
Translation:
Product pages are generated from your translated feeds, so if your database already holds Italian and Polish product data, those pages come out in the right language automatically. For covers, intros, and transition pages, you duplicate the catalog, select the target language, and press generate. The full catalog translates in about a minute, and every translated text box stays editable afterwards for the inevitable resizing when a German word runs longer than its English equivalent. Teams running 12 languages use this to produce all 12 versions from one master rather than 12 separate design projects.
Decentralized creation:
Because layouts are locked templates rather than open design files, the country representative who does not know InDesign can still produce their own regional flyer. They select products from the shared feed, drop them into an approved layout, and publish. Brand control stays centralized. Production moves to the person who actually knows the market. The bottleneck at your one designer disappears.
At scale, data-driven documents break in ways that are invisible until the file is finished.
Teams producing large catalogs usually reach for some form of data merge, scripting product data into the layout rather than typing it. That is the right instinct, and it removes a lot of the typing. What it does not remove is the failure modes, and those only become visible after the document renders in full.
Print preparation adds a second correction layer: preflight warnings, color profile conversion, bleed and trim, font embedding, low-resolution image flags. Each one is a small fix and a full re-export.
Then there is the review cycle, which costs calendar time rather than work time. Three stakeholders reviewing a proof over a week each add days of waiting for edits that take minutes to make. Two proof rounds on a large catalog routinely consume more of the project timeline than the layout did, and the annual catalog with a hard trade-show deadline is precisely where that math becomes a problem.
Layout errors in generated catalogs are template errors, not page errors. Fix the template, regenerate, and every affected page is corrected at once, rather than running background scripts and re-paginating a 12-volume set to resolve a header that overlaps. Static pages that do not come from data, such as terms and conditions, alternate parts listings, or an index, are added into the generated catalog as individual pages, so data-driven and static content coexist in one document without a separate production track for each.
Handing production to an agency converts internal hours into queue time. You stop paying in your team's evenings and start paying a per-project fee, which looks like a good trade until you count what comes with it.
Queue time. Nobody at the agency is sitting idle waiting for your brief. A standard catalog runs one to one and a half weeks, and the urgent single-customer version a rep needs before Thursday is a day at best.
The round trip. Brief, draft, markup, revision, approval. Each leg is a day or more of waiting, so three revision rounds can eat three weeks of calendar time containing maybe six hours of work.
Briefing overhead. Your side still assembles the product list, sources the images, confirms the prices, and writes the brief. A large share of the original workload never left.
File ownership. The agency holds the native files, so the two-minute fix, one wrong price or one discontinued SKU, becomes a ticket, a fee, and a wait. Across a year of small corrections, that flexibility cost outweighs the production cost.
The catalog is no longer your team's workload. It is now your team's dependency.
The agency relationship usually protects one thing: design quality. Catalogy separates that from production. Your agency or in-house designer builds the template set once, then your marketing and sales teams generate catalogs against it without rejoining the queue for every customer-specific version. The one-off that cost a day of agency time takes minutes internally, and the flagship seasonal catalog still gets real art direction.
Existing design work does not need rebuilding. InDesign files can be imported as PDFs, directly or through the Adobe Creative Cloud integration, and used as base pages with interactive and locked elements layered on top.
The initial build is a one-time cost. Updates are permanent. And in most manual workflows, an update costs a meaningful fraction of a full rebuild.
The reason is structural. In a page-based document there is no link between the source data and the page, so an update is not a data change, it is a document change. Nine price corrections mean opening the file, finding nine products across nine pages, editing each one, checking nothing reflowed, re-exporting, re-approving, and redistributing. Teams managing catalogs this way consistently report about a week per update round.
That week is why catalogs go stale in the field. A change that costs a week does not get made for nine SKUs. It waits for the next full cycle, and in the meantime every distributed copy is a little bit wrong. Sales agents know it, so they stop trusting the catalog and start calling the office to confirm prices, which moves the cost from marketing to sales without anyone noticing it happened.
There is also the redistribution problem. Even after the file is corrected, the old version is still in your customers' inboxes, still on the reseller's portal, still on the tablet the rep took to the trade show. Correcting a PDF does not uncorrect the copies already in circulation, so every update generates a second round of work: resending, re-embedding, and asking people to please use the new one.
Worth noting for anyone building a business case: the pain point that moves procurement is rarely the price of the tool. It is the compounding cost of the delay.
A Catalogy catalog stays connected to the feed it was generated from. When a price changes in your spreadsheet, PIM, or ERP, you press sync and the catalog updates, including the version already sitting in a customer's inbox or embedded on your website. The link does not change, so nothing has to be resent, re-embedded, or re-announced.
This is the structural difference between a PDF and a live catalog. A PDF is a snapshot of a moment that has already passed. A live catalog is a current view of your product data. The nine-SKU price correction that was not worth a week of rework becomes a one-click sync, which means your sales agents stop quoting from a version they know is partly wrong.
Break a catalog project into its real components and a pattern appears:
The first two deserve weeks. The last two are what consume them.
Catalog automation is the practice of separating those layers: design the template once, then generate the product pages from a structured data source, so that layout stops being a per-product cost. When a catalog is generated from a product feed against approved templates, a 500-product catalog is produced in seconds rather than weeks, and an update is a data sync rather than a redesign.
Here is the whole process, in the order you would actually do it:
The catalog does not take six weeks because it is hard. It takes six weeks because someone is cropping the four hundredth product image on a Thursday evening, and next quarter someone will do it again.
Look at where the hours go and almost none of them are strategic. Choosing which products to feature matters. Writing the brand story matters. Reflowing 160 pages because someone added an item on page 40 does not. That layer is mechanical, it repeats every cycle, and it is the reason the timeline is what it is.
Catalog automation removes that layer and leaves the rest alone. Design the template once, generate the pages from your product data, and a 500-product catalog takes seconds instead of weeks, an update is a sync instead of a rebuild, and every version stays on brand because it came from the same locked template.
So the useful question is not how long your catalog takes. It is how much of that time is genuinely yours to spend.
How long does it take to make a product catalog?Between 3 weeks and 3 months for most B2B catalogs, depending on SKU count, number of language or channel versions, and how much layout is done manually. Short flyers take hours to a week. Catalogs above 200 pages commonly take 2 to 3 months. Automated catalog generation from a product feed reduces the layout stage to minutes, leaving product selection and content as the remaining time cost. Catalogy generates catalogs of several hundred products in seconds from a spreadsheet or PIM feed.
How long does it take to update an existing catalog?In manual workflows, roughly one week per update round, because changed products must be re-placed by hand and the document redistributed. In feed-driven systems, updates are a data sync and the published catalog updates in place, so the same link stays current without being resent. This is how updates work in Catalogy.
Why do large product catalogs take months to produce?Because manual layout cost scales linearly with SKU count, and large data-driven documents require pagination, error correction, and rework that cannot be predicted before the file is finished. Teams producing multi-volume catalogs commonly report several days of correction work per cycle on top of the layout itself.
Is it faster to use an agency or to produce catalogs in house?Agencies remove internal hours but add queue time, typically one to one and a half weeks per catalog and at least a day for urgent requests. In-house production with manual design tools is faster to initiate but consumes internal capacity. Feed-driven catalog software is generally fastest for recurring and high-SKU catalogs, while agencies remain a reasonable fit for one-off flagship publications with heavy custom art direction.
How fast can a catalog platform be implemented?Most teams reach their first live catalog within 2 to 5 weeks, with the timeline driven by template design and data readiness rather than the software itself. Catalogy typically builds the first catalog and workflow together with the client, then scales to the remaining catalogs from that template set.
