I spent years writing inside enterprise CCMS platforms before I started Topicary. The architecture of structured authoring is correct. The price of admission, for any team smaller than fifty writers, is not. This article is the long version of that sentence. It covers what enterprise CCMS gets right and where it breaks for small teams. It also covers the deliberate tradeoffs we made building a smaller alternative.
I am going to name tools. I am going to be specific about prices and admin overhead where I can verify them. And I am going to name what the tool does not do and who should not use it. This is not a sales pitch. If you want to know where the seams are, keep reading.
What enterprise CCMS gets right
Enterprise CCMS platforms exist for real reasons. Four of them are worth taking seriously.
Governance at scale. When you have 50 writers, 12 reviewers, 4 translation vendors, and 6 product lines, you cannot run reviews in Slack. You need role-based permissions, workflow states, branching, locking, and content ownership at the topic level. Platforms like RWS Tridion Docs and MadCap IXIA CCMS are designed around this. They make a 50-person operation possible. They make a 5-person operation feel like wading through molasses.
Regulatory audit trails. Medical device manufacturers operating under FDA 21 CFR Part 11. Aerospace teams producing technical publications under ATA iSpec 2200 or S1000D. Pharmaceutical writers in a validated GxP environment. These industries require attributable, immutable records of every content change, every approval, every reviewer signoff. Enterprise CCMS platforms ship this as a first-class feature. Most lighter tools do not. "We will add it later" is not a credible answer with an FDA auditor in the building.
Translation memory integration. A serious translation pipeline runs through a translation management system: Trados, memoQ, XTM, Phrase. It carries segment-level translation memory and terminology databases. Enterprise CCMS platforms export XLIFF, round-trip translated content back into source files, and integrate with the major TMS vendors. For teams shipping documentation in 12 languages, this is not optional. The integrations save real money against a workflow of sending Word files to a translation agency. Routinely six figures a year.
DITA specialization. In certain industries, information types are formally defined. A <task> topic must have prerequisites, steps, and a result. A <reference> topic must have a syntax block. DITA's specialization mechanism lets you enforce that at the schema level. Companies with thousands of topics and dozens of writers benefit from this rigor. The OASIS DITA standard is the most mature topic-based information model in the industry. The tooling around it is genuinely capable: DITA Open Toolkit, Oxygen XML, FrameMaker.
I am not going to pretend any of this is fake or optional. If you need these features, the enterprise CCMS market is the right market for you. Look at Paligo, Heretto, MadCap IXIA, and RWS Tridion Docs. Read the honest framing for what a CCMS actually is before you start evaluating.
Where enterprise CCMS breaks for small teams
The strengths above all assume a particular shape of team. Fifty writers. Specialized roles. A standing budget line for documentation tooling. A regulatory or translation context that justifies the overhead. Remove any one of those assumptions and the platform stops fitting.
I have watched four specific failure modes repeat across teams.
XML scares off writers. MadCap Flare ships a modern visual editor. It still exposes its underlying XHTML and condition tags to non-technical contributors. DITA editing in Oxygen or FrameMaker is even more direct. You are writing <concept> and <conbody> and <shortdesc> elements. A misplaced angle bracket invalidates your build. Marketing managers, product managers, and SMEs will not learn this. Teams end up with a two-tier system. "Real writers" use the CCMS. Everyone else writes in Google Docs that someone manually reformats.
Licensing prices out small teams. The enterprise CCMS tier starts around $50,000 a year and climbs from there. MadCap IXIA CCMS lists a starting rate of $3,850 per month on Capterra. Heretto is reported at $150 to $250 per author per month on TrustRadius. RWS Tridion Docs is quote-only and pitched at "thousands of users in one governed environment." For a 5-person team, the per-seat math makes no sense. Implementation services typically cost another $30,000 to $80,000 before you publish a single page.
Admin overhead requires a dedicated role. Sarah O'Keefe at Scriptorium and Bill Swallow at DITA Strategies both describe the information architect role as a permanent position in serious DITA shops. Not a part-time duty. Someone owns the content model, the taxonomy, the publishing pipelines, the user roles, and the ongoing platform tuning. On a 5-writer team, that person does not exist. The documentation lead is also the writer. The CCMS becomes a part-time second job that no one signed up for.
Publishing pipelines take weeks to configure. Enterprise CCMS implementations are measured in months. A typical DITA-CCMS rollout, in my experience, runs 3 to 9 months before the first production publish. You spend that time configuring custom output pipelines in the DITA Open Toolkit. You map CSS to PDF page layouts in FrameMaker or AntennaHouse. You wire up the build infrastructure. None of this is wasted work if you have the scale to amortize it. At 5 writers, you will spend more on the consultants than the platform license.
The named tools each have their own version of these problems.
MadCap Flare
Flare is a powerful authoring tool with a serious learning curve. Its strengths (single-source publishing, target-based conditional output, deep CSS control) are real. Its weaknesses are structural. Projects live on disk as a tree of XHTML topics plus a .flprj project file. Multi-writer collaboration runs through MadCap Central or a Git-based workflow that requires every writer to manage merge conflicts in XHTML. The condition tag system is powerful but unforgiving. And the desktop authoring experience is Windows-only. Flare Online exists but requires a Central subscription. That is still a friction point for Mac-first teams.
If you are coming from Flare specifically, the Flare migration guide walks through what carries over and what does not. The high-level reading: Flare's information model is closer to Topicary than to DITA. Its target and condition system is more elaborate than a small team needs.
Paligo
Paligo is the cleanest DITA-shaped CCMS in the SaaS tier. It uses DocBook internally rather than DITA, but the topic-and-map authoring experience is similar. The platform is genuinely well-built. It also has a steeper ramp than its marketing suggests. Writers without prior structured-authoring experience routinely need four to six weeks of training in the visual editor. The hard parts are conditional profiling and content reuse. Pricing is quote-based and not published. Reports on Vendr and G2 suggest deals start in the low tens of thousands per year. They climb with seat count and TMS integration. The direct Paligo comparison page breaks down the seam-by-seam differences.
IXIASOFT (MadCap IXIA CCMS) and RWS Tridion Docs
These are the heavy DITA platforms. Both are excellent at what they do. Both assume you have an information architect, a publishing engineer, and a translation vendor on staff. IXIA's starting price is in the high $40K range annually. Tridion Docs does not publish pricing and is sold through enterprise sales. Implementation services for either typically add another $50K to $150K depending on customization. If your team has those problems to solve, these are the platforms to evaluate. If you do not, you will spend a year configuring a system you outgrow in two directions. Too complex for the team. Not complex enough for the next tier of compliance.
The honest summary, as a comparison:
| What you need | Right tier | Wrong tier |
|---|---|---|
| 50+ writers, role-based governance | Enterprise CCMS (Tridion, IXIA) | Lightweight CCMS |
| FDA 21 CFR Part 11 audit trail | Enterprise CCMS | Wiki, lightweight CCMS |
| TMS integration, 5+ languages | Enterprise CCMS | Wiki, lightweight CCMS |
| DITA specialization, conref interoperability | Paligo, Heretto, IXIA, Tridion | Topicary, GitBook, Mintlify |
| 5 to 15 writers, multi-channel publish, no regulated review | Lightweight CCMS (Topicary, ClickHelp) | Enterprise CCMS, wiki |
| Solo writer, single output | Wiki, docs-as-code | Any CCMS |
Four design decisions that defined Topicary
When I started building it, I made four decisions early. Each one was a tradeoff, not a free win. The honest version of the product story is naming both sides.
1. Structured authoring without DITA. Topicary uses TipTap (a rich-text editor based on ProseMirror) as its authoring surface. Topics are stored as JSON, not XML. Writers see formatted text with inline component references, condition blocks, and variable tokens. They do not see angle brackets. The tradeoff: Topicary cannot import or export DITA with round-trip fidelity. If your organization needs DITA interoperability with outside vendors, this is a hard blocker. The longer argument lives in the DITA alternative breakdown.
2. Cloud-native, no on-premise. Topicary runs as a multi-tenant SaaS on Supabase and Vercel. There is no self-hosted edition and no plan to build one. The tradeoff: organizations with on-premise mandates cannot use Topicary at all. That means most defense contractors, most financial services firms, and certain healthcare environments. This is not a limitation we are working around. It is a deliberate scope cut.
3. Topic-based but not XML-based. The information model is topic-based: maps, conditional profiling, variables, component reuse. DITA introduced the same architectural primitives in 2005. The serialization is JSON and rendered markdown for export, not DITA XML. The tradeoff: no DITA specialization. You cannot define a custom <medical-device-warning> topic type with required <contraindications> and <dosage> elements enforced at the schema level. For most teams this never matters. For teams in regulated specializations, it matters a lot.
4. Token-based SME review. Reviewers do not need an account. The author generates a tokenized link and sends it by email. The reviewer comments and approves topics in a browser. The tradeoff: token-based review does not produce a regulatory-grade audit trail. The token is single-purpose and revocable, but the approval is not attributable in the way FDA 21 CFR Part 11 requires. If your reviews need to satisfy regulated-industry audit standards, read our analysis of the SME review problem. It is honest about where token review fits and where it does not.
The features I deliberately did not build
I want to be specific about anti-features, because vague "we focus on simplicity" lines hide what a product actually does not do. Four features that enterprise CCMS platforms have and the platform does not, and why:
No DITA native authoring. XML scares off the non-technical contributors who do at least a third of the writing on small teams. The information model from DITA is present. The serialization is not. If your team needs to author and exchange DITA directly, use Paligo, Heretto, IXIA, or Tridion.
No translation memory or TMS connector. Translation pipelines built around segment-level memory and TMS integration add real complexity to the product. They add real cost to the customer. Most teams under 15 writers either publish in English only or work with a human translation agency directly. A TMS connector would satisfy the 10 percent of customers who would use it. It would degrade the product for the 90 percent who would not. If you need XLIFF round-tripping with Trados or memoQ, this is not your tool.
No regulatory audit log. FDA 21 CFR Part 11, aviation traceability under ATA iSpec 2200, and pharmaceutical GxP compliance are different product categories. They require validated software, change-control documentation, attributable signatures, and immutable records that meet specific regulatory tests. Building this credibly is a multi-year, multi-million-dollar investment. We have no plans to do it. If your industry requires it, the right platforms are RWS Tridion Docs and MadCap IXIA. A small number of DITA CCMS vendors serve regulated verticals too.
No on-premise deployment. Maintaining infrastructure is not what a 5-person documentation team should spend time on. The premise that customers want to host their own CCMS is a premise from 2010. Back then SaaS was not yet credible for serious enterprise software. We chose cloud-native and we are not adding self-hosted as an option.
Who Topicary is not for
The features above translate into a clear list of teams that should not buy it. I would rather be honest about this in writing than waste anyone's evaluation cycle.
- You need DITA-native authoring. Use Paligo, Heretto, MadCap IXIA, or RWS Tridion Docs.
- You need regulatory audit trails for FDA, aviation, or pharma compliance. Use an enterprise CCMS designed for the regulation.
- You need on-premise deployment. Use a self-hosted enterprise CCMS or a docs-as-code workflow with internal hosting.
- You have 50 or more writers needing role-based governance. Topicary is built for 2 to 15 writers; the workflow primitives stop scaling past that point.
- You need translation memory integration with a TMS. Use a platform with first-class XLIFF and TMS connector support.
- You are a solo writer with simple needs. Use Notion, Markdown plus Git, or a static-site generator. A CCMS is overkill.
If three or more of those describe your situation, stop reading and go evaluate the right tier of tool. Lightweight CCMS is not a universal upgrade path.
What I am still wrong about
The honest part of any founder story is what is still missing. Three things I expect to keep wrestling with:
Reuse discipline does not come from the tool. Good tooling makes component reuse mechanically easy. It cannot make teams agree on what is a reusable component and what is a one-off. The enterprise CCMS tier handles this with an information architect role. The lightweight tier needs better defaults and editorial guidance built into the product. We are not there yet.
The boundary between "topic" and "component" is genuinely fuzzy. DITA draws this line at the schema level. We draw it at the user's discretion. Both approaches have failure modes. The DITA failure mode is over-constrained authoring. Our failure mode is content that should have been promoted to a component but never was. Drifting copies appear in three topics. We will keep refining this.
AI changes the small-team CCMS equation in ways I do not fully understand yet. Topicary ships with AI-assisted drafting, content findings, and chat tools that assume an LLM context window over the project. The architecture is real. The early results are promising. The long-term shape of how AI changes structured authoring is genuinely unsettled. I am skeptical of anyone who claims certainty on this in 2026.
I would rather end with that uncertainty than a closing flourish. Tooling is one part of a documentation operation. Process and editorial discipline are the others. If your bottleneck is the process, the best CCMS on the market will not save you.
Frequently asked questions
Is enterprise CCMS still worth it in 2026? For teams of 20 or more writers with regulatory, translation, or governance requirements, yes. For teams under 15 writers without those requirements, the math does not work — the per-seat pricing and dedicated administrator overhead exceed the value.
Why did you not build DITA support into Topicary? Because the XML schema is the part of DITA that scares off non-technical writers, and they do most of the writing on small teams. The information model from DITA is in the product; the XML serialization is not.
What is the real cost of an enterprise CCMS for a 5-writer team? Between $50,000 and $200,000 in the first year, depending on platform and implementation services. The license is rarely the largest line item — implementation, training, and translation setup typically add another $30,000 to $80,000.
What does Topicary deliberately not do? Four things: no DITA-native authoring, no translation memory, no regulatory audit log, no on-premise deployment. Each is a real feature in enterprise CCMS and a real reason a team might rule us out.
Why did you choose token-based SME review instead of a login flow? Because account creation is the single biggest reason review cycles stall when subject-matter experts are involved. The tradeoff is that tokenized review does not produce a regulatory-grade audit trail.
Will Topicary ever support on-premise deployment? Probably not. If your organization requires self-hosted infrastructure for security or regulatory reasons, an enterprise CCMS with a self-hosted edition is the right tool — not us.