u/fazkan

Credits: Tom Qin

Launching a product on Product Hunt today after repeatedly seeing AI-generate documentation that still looks vibe-coded.

So I built a product that lets coding agents turn a plain-English prompt into polished documentation with clear structure and consistent design.

It’s a niche idea. But if it resonates with you, I’d really appreciate your support on Product Hunt today.

Link to product hunt launch.

https://www.producthunt.com/products/docsalot-2/launches/docsalot-cli

Hey everyone, doing a second launch after a month for the same product today. The last time we reached #2.

The CLI lets your your coding agent create, preview, push, and publish docs from scratch. All from a plain prompt.

If the product resonates, I would really appreciate you checking out the launch

https://www.producthunt.com/products/docsalot-2/launches/docsalot-cli

I have a developer docs platform, we help people build their API docs, developer docs and help-centers, and host them.

Last week, I shipped an MCP server for readers questions that users were asking on our customers docs.

The MCP can:

• summarize what readers asked over the last 7, 30, or 90 days
• compare activity with the previous period
• recommend the next help-desk or knowledge-base improvements

Not only for our customers, but personally for me it has been acting as a product-manager. Most readers questions are about the product than the docs.

It has definitely informed my product direction.

One thing I think more SaaS products need to take seriously:

the dashboard should not be the only place where work can happen.

Dashboards are useful for visibility, review, and confidence. But if a team is using agents to maintain a help-desk or knowledge-base, it feels broken when the agent can help with 90% of the workflow and then says:

"Now go click around in the dashboard to finish this."

That handoff slows down work and makes automation feel less real.

So this week, we shipped custom domains from the DocsAlot CLI.

• start custom-domain setup outside the dashboard
• tell the user what DNS record needs to exist
• verify the domain once DNS is ready
• keep the workflow available for agents and scripts

If your DNS is on Cloudflare, the goal is that you can ask:

"Point this knowledge-base to docs.yourdomain.com."

And your agent should be able to handle the operational steps around that request.

What this unlocks

A founder or small team can move more of the knowledge-base workflow into the same place where they already write, review, and publish content.

The unfair advantage is simple: if your help-desk can be operated by humans and agents, it becomes easier to maintain and faster to improve.

Curious how many other SaaS teams still have important workflows trapped behind dashboard clicks.

I do weekly releases to keep myself accountable.

One pattern I am seeing more often:

People are letting AI agents work with their documentation CLI directly.

The agent creates or edits files, runs a local preview, opens the browser, and uses Computer Use to inspect what changed.

That is a really powerful workflow, but it depends on one boring thing being true:

The preview has to show the latest content.

We had a long-running bug where local file changes did not always show up until the user hard refreshed the page.

For a human, that is annoying.

For an agent using browser feedback, it is much worse. The agent may be judging an old version of the help-desk or knowledge-base and making the wrong next decision.

So this week, we shipped quality-of-life improvements in the DocsAlot CLI:

• local preview changes now show up automatically
• the browser refreshes when docs content changes
• preview pages read from the latest filesystem state
• local preview uses a randomized local admin token fallback
• navigation generation is more defensive when layout.json references missing pages or unsupported objects

What this unlocks

Teams can let humans and agents work on a knowledge-base locally with a much tighter feedback loop.

That means faster cleanup, faster migration, and less babysitting when an agent is iterating through content changes.

If your knowledge-base workflow is reliable enough for humans and instant enough for agents, that becomes a real execution advantage.

I do weekly releases to keep myself accountable.

I have done many launches, not a single one got featured.

This one got featured.

Following are simple things.

1. Make sure your landing page is professional and does not look vibecoded.
2. Make a video with something like arcade, that shows the problem you are solving, not a video of how the dashboard works.
3. make an onboarding simulation, there are softwares for that, you can google we used arcade for that as well.
4. Make sure the image are high quality.

These are the highest moving things. that worked.

I know this because after my last lauched I reached out to the PH support. Now that I think about it, maybe that helped as well.

Small side note: would really appreciate an upvote if you have a moment to spare. Happy to answer any questions.

https://www.producthunt.com/products/docsalot-2

Small Canada Day ship from Montréal.

I’m building DocsAlot, a documentation platform, and today we added language-aware docs support. The first language we tested this with is French.

It felt like the right day for it. Canada has two federal official languages: English and French. French is the first official language spoken for about 22% of Canadians, and almost 10.7M Canadians can carry on a conversation in French.

The update adds:

• language dropdowns
• translated navigation
• localized documentation sections
• French getting started docs
• French API reference pages

Most teams can keep a knowledge-base inside one system right up until they want a polished homepage, splash screen, or onboarding-style layout.

Then they end up splitting the experience across two surfaces: one place for the help-desk, another place for the nicer custom landing page.

So we shipped:

• page modes for different page shells, including default, wide, center, frame, and custom
• a custom mode for building splash-style help-desk pages inside the knowledge-base itself
• hosted custom.css support
• preview and publish fixes so shipping those pages is less fragile

What this unlocks:

Teams can keep one knowledge-base instead of splitting the first-screen experience from the rest of the help-desk.

That means a cleaner onboarding path, a more polished support surface, and less operational overhead.

I think that is an underrated advantage if you want your help-desk to work for customers, writers, and AI systems at the same time.

Curious how other founders handle this today: do you keep your help-desk and onboarding pages together, or split them across different tools?

I do weekly releases to keep myself accountable.

One thing that seems increasingly broken in product docs: teams are trying to use one navigation model for completely different workflows.

A knowledge-base reader wants guides and setup steps. An API user wants endpoint discovery. A team working with AI tools may also want app docs or MCP docs in the same product surface.

Once the API reference gets large, that usually turns into a messy sidebar, buried endpoints, or a separate site that no longer feels connected to the rest of the help-desk.

So this week we shipped tabbed navigation and better OpenAPI reference handling in Docsalot.

• teams can now define top-level tabs in layout.json
• the sidebar can change based on the selected tab
• large API references can be organized into cleaner nested sections instead of one long navigation tree
• auth details and playground request paths can now resolve from the OpenAPI spec itself

What this unlocks

You can keep your guides, help-desk content, knowledge-base pages, and API reference in one product without making the navigation unusable.

The unfair advantage is pretty simple:

if your help-desk can serve different audiences cleanly without splitting into disconnected surfaces, it becomes easier to adopt, easier to maintain, and more useful for both humans and agents.

Curious how other teams handle the point where a growing API reference starts overwhelming the rest of the knowledge-base.

I do weekly releases to keep myself accountable.

This week, I focused on a less flashy but important part of DocsAlot: making the editor feel better during normal day-to-day use.

When people are working on a help-desk or knowledge-base, the small bits of friction matter.

If the page takes too long to open, the file tree jumps around, the loading state is unclear, or the editor says there are unsaved changes when nothing changed, it breaks trust.

So we shipped a set of editor quality-of-life improvements:

• faster documentation opening
• smoother page switching
• better loading states
• a more stable file tree while moving between pages
• fewer false "unsaved changes" states
• clearer feedback while loading and publishing
• more instrumentation so we can catch slow paths sooner

What this improves:

The editor should feel calmer and more predictable when teams are updating real documentation.

You should be able to open a page, make a change, switch files, and publish without wondering whether the UI is keeping up.

Not the flashiest release, but these are the kinds of improvements that make a product feel usable every day.

Curious how much this matters to other founders: do you notice these small editor details when evaluating tools, or only when they break?

I do weekly releases to keep myself accountable.

One thing that keeps getting more important: people are no longer always entering a help-desk or knowledge-base from the homepage.

They are landing on deep pages from search, shared links, old bookmarks, support conversations, and now AI-generated answers.

That means a generic 404 page is not just a minor UX issue anymore.

It breaks trust, wastes self-serve intent, and makes a knowledge-base feel unreliable right when someone is actively looking for help.

So this week we shipped tenant-aware 404 handling in Docsalot.

• A missing page inside a known documentation site can now render a branded 404 inside the existing help-desk shell
• teams can control the 404 title, description, and redirect behavior from layout.json
• missing-page flows can send users back to the right entry point instead of dropping them into a generic global error page
• tenant context is preserved across redirects, so recovery behaves more predictably

What this unlocks

Broken links can now become recovery paths instead of dead ends.

That means customers stay inside the right knowledge-base, teams keep more self-serve sessions alive, and older links do less damage as documentation evolves.

The unfair advantage here is simple:

if your help-desk can recover gracefully when pages move, it becomes a much more reliable surface for both humans and agents.

Curious how other teams handle stale knowledge-base links today.

I do weekly releases to keep myself accountable.