The docs market looks crowded if you count the number of vendors. It looks a lot less crowded if you look at the documentation most teams actually ship That's the short version of why I think DocsAlot should exist. Its customer driven, not investor driven.
I am not arguing that competition does not exist. It obviously does. I am saying there is plenty of room at the bottom 1.
Mintlify is large and still growing. GitBook is established. Scalar has a strong API-first position. Docusaurus, Fumadocs, starlight are solid open-source options. There are plenty of smaller tools too.
But "there are competitors" is not the same thing as "the market is closed."
One of the cleaner explanations of this came from Max Rozen, who wrote about building OnlineOrNot in a category with roughly 200 listed alternatives. His point was not that competition is fake. It was that markets are messier and product fit is uneven. Buyers are rarely choosing from a tidy spreadsheet of ten well-understood options. A lot of them are using whatever they already know, whatever a friend mentioned, or whatever happened to show up first.
That framing matches what I see in documentation.
The docs market is not one market
People talk about "documentation platforms" as if they all solve the same problem. They do not.
From where I sit, the category is splitting into at least three different models.
1. AI-native and automation-first products
This bucket is optimizing for structured specs, generated SDKs, machine-readable outputs, agent access, and automation pipelines.
Mintlify is a clear example of this. Even the product framing has moved well beyond "nice docs site." The company now describes itself as an intelligent knowledge platform, with features around AI answers, agent analytics, llms.txt generation, and an MCP server. The direction of travel is obvious: not just hosted docs, but infrastructure for knowledge consumption by both humans and machines. A common pattern when you have raised a lot of money is to expand the vision and the product at the same time. That is what I see happening here. If they go along this direction, expect customer support bots like Pylon, as that's a bigger market.
Fern is in a similar family, but from the API side. The core pitch is spec-first API infrastructure: generate SDKs, generate docs, keep them aligned, and increasingly support agent-readable surfaces like llms.txt and MCP. It is a serious product for teams that want their API surface treated like a system, not just a website. Fern recently was acquired by Postman, which is another sign that this side of the market is converging with broader API platform infrastructure rather than staying a narrow docs category forever.
These are not bad products. They are doing the rational thing. But once a company starts expanding in that direction, the product changes.
2. Human-native workflow platforms
This bucket is stronger when the problem is editorial workflow, internal collaboration, permissions, review loops, and narrative authoring across teams.
GitBook is the obvious example. It has a strong editor, collaborative workflows, permissions, publishing controls, AI answers, Git sync, and an MCP server. That makes sense if your real problem is not "render my API reference beautifully," but "help multiple humans across support, engineering, product, and solutions keep a large knowledge surface coherent."
That is a real need. It is just a different one.
3. Open-source frameworks
Then there is the third category: tools like Docusaurus and Fumadocs.
These are not really "buying a docs platform" in the SaaS sense. They are frameworks. They give you a strong starting point, but you still assemble and run the system yourself. You choose hosting, deployment, content workflow, permissions, previews, analytics, and whatever agent-facing pieces you want to bolt on.
That distinction matters because people often look at a list that includes Mintlify, GitBook, Docusaurus, and Fumadocs and conclude that the category is saturated. I think that is the wrong read. What I see instead is fragmentation. These products are solving adjacent jobs, not identical ones.
Why I think documentation demand goes up from here
The bigger reason I am comfortable building in this market is that I think the need for documentation is increasing.
APIs are moving closer to the default
I do not mean every product will expose a perfect public REST API next quarter. The transport does not matter that much. Some products will expose APIs. Some will expose agent actions. Some will expose MCP-compatible tooling. Some will wrap existing product surfaces in a machine-friendly layer later.
The underlying pressure is the same: software is becoming more composable, and products that are easy to integrate into automated workflows have a large advantage.
That changes the role of docs. Documentation used to be downstream from the product. Build the thing, then explain it. But increasingly, documentation is part of the interface.
If a user is onboarding through a coding agent, the docs are no longer just a support artifact for a human engineer skimming examples. They are part of the material that lets the agent understand what the product is, what operations are available, what the constraints are, and how to combine actions safely.
More people are going to act like developers
I also think the total number of people producing software behavior is going up because AI is making software construction more accessible.
That does not mean everyone turns into a strong software engineer. It means more people can express intent in software-adjacent ways: shipping workflows, wiring tools together, automating ops, building internal utilities, and standing up small products without traditional teams.
Whether you call them developers or not is secondary. The important part is that they still need interfaces they can understand and trust.
More builders means more APIs, more integration surfaces, and more documentation demand.
This is one of the places where I think people underestimate the second-order effect of coding agents. Even if code generation gets easier, the surrounding coordination problem gets bigger. More software gets made. More endpoints exist. More tools become partly programmable. More documentation has to exist to explain all of that to humans and to machines.
Docs now need human and machine affordances
The docs page is no longer the whole artifact.
Now you also need the machine-readable and agent-discoverable layer around it: llms.txt, MCP endpoints, skill files, structured reference, and other small artifacts that make a product legible in AI-native workflows.
The good news is that these are not especially hard to produce once you have the right source of truth.
The bad news is that if you do not produce them, your product becomes less visible and less usable in the workflows that are growing fastest.
That is another reason I do not think this category collapses into a few incumbents. The requirements are expanding.
Why strong competitors do not close the market for a smaller product
The strongest argument against building DocsAlot is obvious: why enter a market with credible incumbents?
My answer is that incumbents do not just create competition. They also create openings.
As companies raise more money, move upmarket, or get pulled into adjacent categories, they usually get broader. That is rational. Customers ask for more workflow, more enterprise controls, more AI, more governance, more analytics, more collaboration, more import paths, and more content types.
That is how a clean product turns into a platform.
Sometimes that broadening creates a better product. Often it creates a heavier one. We have all seen what happens when a sharp tool keeps absorbing new obligations.
I am not using "enshittification" here as a slogan. I mean something simpler: products accumulate obligations. They stop being allowed to stay narrow. They have to serve more segments, more stakeholders, and more edge cases than they originally did.
That broadening is one of the main reasons small products can still win in seemingly crowded categories.
From the outside, a company like Mintlify looks like a docs competitor. And it is. But it is also increasingly an AI knowledge product. GitBook is a docs competitor, but it is also a workflow and knowledge collaboration product and a customer support bot. Fern is a docs competitor, but it is also an SDK generation product. Docusaurus and Fumadocs are alternatives, but they are really framework choices.
That leaves room for a narrower thesis.
The thesis for DocsAlot
The DocsAlot thesis is not "we will beat everyone by having every feature." That is the fastest way to become mediocre.
The thesis is smaller:
- Make good-looking public docs.
- Keep them in sync as soon as people commit doc changes.
- Make the docs legible to agents as well as humans.
That sounds almost too small, but I think that is the point.
There is a lot of demand for a product that does one thing well: take docs-as-code seriously, publish something attractive, keep it updated without ceremony, and generate the adjacent machine-facing assets that now matter.
Not an internal wiki. Not an all-purpose knowledge platform. Not an everything suite for docs, support, product education, and AI governance.
Just a sharp, opinionated product for teams that want their docs to look good, stay current, and be easy for both people and agents to consume.
That is especially interesting to me because the failure mode in docs is often not "we picked the wrong platform." It is "we stopped maintaining the docs because the workflow was too annoying." Or "the docs were technically there, but the public experience was bad." Or "the product worked for humans but had no machine-readable discovery layer." Or "the framework was flexible, but now we are maintaining a docs stack instead of shipping the product."
A smaller product can take those failure modes more seriously because it is not trying to solve seven adjacent problems at the same time.
Competition matters less than clarity
The part of Max Rozen's argument that stuck with me is that the existence of many competitors does not mean the buyer is seeing all of them clearly. Often they are seeing almost none of them clearly.
That feels true in docs. Most teams are not running a perfect market scan of every documentation platform and every open-source option. They are taking recommendations from friends, copying the last tool they used, defaulting to whatever their VP of Engineering already knows, or hacking together the path of least resistance.
That is why I think lack of awareness matters more than competitor count.
If the product is clear, the setup is simple, the docs look good, the sync story is strong, and the agent-facing artifacts are handled automatically, there is still plenty of room to matter.
You do not need to "win the market" in the abstract. You need to become the obvious answer for one kind of team.
For DocsAlot, the bet is that there will be more of those teams over time, not fewer:
- teams shipping APIs faster because agents make software construction cheaper
- teams that want docs-as-code, but not a giant internal platform
- teams that care about aesthetics and readability
- teams that need docs to be understandable by humans and machines
- teams that do not want to maintain a custom docs stack forever
If that bet is right, the crowdedness of the category matters less than the direction of the category.
My read is that the direction is favorable.
A final note on "crowded"
Crowded markets are often good markets.
They mean the pain is real.
The more important question is whether the pain is solved cleanly for the specific segment you care about. In docs, I do not think it is. The category already contains strong products, but they are increasingly optimized for different ends: platform breadth, enterprise workflow, API infrastructure, or framework flexibility.
I think there is still room for a smaller, more opinionated product that treats documentation as a first-class interface layer, keeps it synced to the codebase, and makes the result legible to both people and agents.
Maybe the market proves me wrong. But "there are already competitors" is not a good enough reason not to build.
If anything, in documentation right now, it is a reason to be more precise about what kind of product you are actually building.
Notes and source material
- Richard Feynman, There's Plenty of Room at the Bottom: An Invitation to Enter a New Field of Physics
- Max Rozen on operating in a crowded market: On four years of running a SaaS in a competitive market
- Docusaurus and Fumadocs as frameworks rather than hosted docs platforms: Docusaurus, Deployment, Fumadocs, Docs