Publishers rarely lose on a shortage of content ideas. They lose on the pace and repeatability of production: a piece waits for sign-off, a designer hunts for the right version of a photo, and a video has to be re-encoded by hand for three platforms. Once these frictions multiply, another CMS plugin stops being enough. What you need is a content production system in which the editorial CMS, the asset library (DAM) and media processing run as one machine.
In our experience, the hard part is not picking a tool but joining the newsroom, the assets and the media into one predictable flow that absorbs a growing volume without adding people to every channel. We have built applications for the media industry, so we know the specifics of content, metadata and many output formats, and we assemble the team around exactly that work.
Why does media content production now need a dedicated system?
The reason is mundane: scale and the number of channels have outgrown the processes. One piece rarely ends as a single article; it fans out to the website, a newsletter, the app, social media and syndication partners, each with different requirements for format and metadata. Without a system, all of this rests on people and their memory: “final” versions multiply, assets duplicate across drives, and the cost of every publication climbs.
A content production system turns that work into a repeatable process: one source of truth, clear working states, and automatic channel-specific variants. This is no longer about newsroom comfort; it is about the unit cost of content.
What is an editorial CMS, and how do you design its workflow?
An editorial CMS is more than an editor and a table of posts. It is a collaboration tool in which content moves through defined roles and states before it reaches the audience. We design it around a given newsroom’s real flow, not the engine’s defaults.
In practice we model several things at once:
- roles and permissions (author, managing editor, copy desk, publisher, administrator), so each person sees exactly what they should,
- states and transitions (draft, in editing, for approval, scheduled, published, retracted) with the conditions required to move forward,
- versioning and change history, meaning the ability to compare who changed what and to roll back,
- scheduling and publishing, including embargoes, scheduled posts and simultaneous publication across several channels.
A good workflow shortens the path from idea to publication while still protecting quality.
How does digital asset management (DAM) bring order to a newsroom’s assets?
Text is only part of the content. Photos, graphics, video, podcasts and source files need their own order, and that is what digital asset management (DAM) provides. A central asset library stops the newsroom chasing files across drives and inboxes, and gives every asset one home, one history and clear usage rules.
When we build the DAM layer, we watch for:
- one source of truth for originals from which we generate variants, rather than multiplying copies,
- search by metadata and content (author, date, rights, tags, and for images also recognised objects),
- relationships between assets and publications, meaning knowing where a given item has already been used,
- version and status control for assets (working, approved, retracted), consistent with the editorial flow.
DAM pays off most where the archive is large and active: it turns a cost into an asset you can genuinely reuse.
How do you build a media transcoding pipeline?
Video and audio do not reach the audience in the format they were created in. They have to be re-encoded, normalised and prepared for specific channels, and at any real volume you cannot do that by hand. So we set up an automatic transcoding pipeline that triggers the moment a new file enters the system.
The pipeline takes the source material, encodes it into several profiles (different resolutions and bitrates for web, app and social), generates subtitles and thumbnails, and deposits the finished variants in the DAM, tagged with metadata. We design it to scale with load, not with the number of operators: more files means more parallel jobs, not more overtime.
Which metadata and taxonomy keep this system under control?
Metadata is the nervous system of the whole setup. Without it, even the best CMS and DAM turn into a good-looking junk drawer, so we design the taxonomy up front, not after the fact.
We agree on a shared metadata model for content and assets (topic, category, tags, language, rights, relationships), we keep consistent vocabularies so that “sport” and “Sport” are not two categories, and we prepare the structure for search and recommendations. Where it makes sense, we support tagging semi-automatically, suggesting categories and recognising objects in photos, but we leave the decision to the newsroom. Taxonomy is what decides whether the archive stays searchable and content can be linked intelligently.
How do you stay on top of content rights and licences?
In media, the rights to a piece can cost more than producing it, and a mistake can cost real money and reputation. So we treat rights and licences as first-class data, wired into the asset’s metadata rather than parked in a spreadsheet alongside it.
The system tracks where an asset comes from, on what terms and for how long it may be used, and in which channels and territories, and it flags an expiring licence or use outside the permitted scope. This control does not slow the newsroom down; it removes risk, because the “allowed or not” decision is visible the moment someone picks a photo.
Headless or monolith: how do you choose a CMS architecture?
This is one of the first architectural questions, and there is no single right answer. A monolithic CMS keeps content and presentation together, so it starts faster and is easier to manage for one main channel. A headless CMS separates content from the presentation layer and exposes it through an API, which pays off when the same material feeds many frontends: the site, the app, a TV, a speaker, partners.
We advise on the choice based on the number of channels, the pace of change and how independent the product teams should be from the newsroom. We often build hybrids: a headless core serves content through an API, with a convenient editorial tool layered on top. The key is that the architecture should follow how content is distributed.
Which skills do we provide for a content production project?
Even if we have not delivered this exact CMS rollout for a given publisher, we supply people who build systems of this kind. We shape the team around the specific scope, not “just in case”, and most often we staff:
- a solution architect who picks the model (headless/monolith) and designs the content flow and integrations,
- backend developers building the content API, workflow, metadata handling and permissions,
- media and DevOps specialists who set up the transcoding pipeline and the infrastructure for scale,
- frontend engineers / integrators who join the CMS to the output channels and the publisher’s existing systems.
Such a team slots into the existing ecosystem instead of demanding a rebuild around a new tool.
How do we do it at RITS?
We do it as a nearshore partner from Poland that adds skills exactly where publishers lack them:
- we assemble a team to fit the scope of the project (CMS, DAM, transcoding) and verify skills before the start,
- we join the editorial, asset and media layers into one maintainable whole, instead of stitching loose tools together,
- we work in a close time zone, so our engineers join code reviews and meetings without a long ramp-up,
- where it makes sense, we add an AI/Data layer (tagging, search, recommendations) to support the newsroom, not replace it.
Most often we deliver this as custom software built by our team and, where skills need topping up fast, as team augmentation.
Where to start building a content production system?
Start from the single most painful bottleneck: if pieces get stuck in approval, start with CMS workflow; if assets go missing, start with DAM; if video blocks publication, start with the transcoding pipeline. Add a decision on taxonomy and rights, because those determine the quality of the whole, and build the rest in stages. We covered the differences between engagement models in our article on IT engagement models.
Building or rebuilding a content production system (CMS, DAM)? Let’s talk - we’ll match a team and an architecture to your newsroom.