Sign in

Corilla

Collaborative documentation for software teams.

5.0•2 reviews•

3 followers

Note and writing apps•Project management software•Team collaboration software

Corilla is a collaborative content tool for software teams. Most teams use it for it's original purpose as a documentation tool.

Blog

•

Newsletter

•

Questions

•

Forums

•

Product Categories

•

Apps

•

About

•

FAQ

•

Terms

•

Privacy and Cookies

•

X.com

•

Facebook

•

Instagram

•

LinkedIn

•

YouTube

•

Advertise

© 2025 Product Hunt

Corilla gallery image

Corilla gallery image

Corilla gallery image

Corilla gallery image

Launch tags:

Writing•Developer Tools•Tech

Launch Team

Corilla

Maker

Thanks for the hunt @stringstory and hello everyone! Both @nathan404 and myself will be here all day to answer any questions. Corilla is the product of an active community of technical writers and developers, so we're excited to hear your feedback and learn how we can get better, together. I can also speak a little to the history of Corilla and what inspired us to spin out of the technical content team at Red Hat. PS: we're on Product Hunt now so I guess... this is the end of our beta? 😳 Did we just ⛵️?

8yr ago

Oras Al-Kubaisi

Job Description AI

Hi @davedri, does it have API documentation? does it support importing from other resources (like github pages)?

8yr ago

Corilla

Maker

@orask In terms of API documentation, we have this on the roadmap but feel that there's some great products in that space at the moment. We wanted to focus first on where the greatest pain was present for technical writers and developers (e.g. all of us) and not replicate what other great companies are doing. It's interesting to note that the various documentation startups tend to get on really well. After all, we care about the same things. Corilla's focus on APIs is a little different to those that emerged as a result of the inspiration of Stripe (and Slate), but that's a way off. As for the importing workflow, that's on the roadmap and something we're adding very soon. I've created a public roadmap entry for this: https://trello.com/c/iNEOB4Q7/21...

8yr ago

Oras Al-Kubaisi

Job Description AI

@davedri Thank you. I agree there are lots of good API docs but here comes the other issue that we (technical developers) suffer from which is documentation all over the place. Great to see your public roadmap, all the best!

8yr ago

Corilla

Maker

@orask that's a good point. One of the things we like about Corilla as devs and writers is that it bundles the workflow together. Being able to write a topic as a team, collect them into collections, compare version control, and publish to a range of outputs... that alone in one tool would have seemed like the holy grail back in my early techcomms days! Makes me smile to have it all in Corilla now. I hope we can make you smile when we ship our take on the API... 😃 In the meantime please keep those great ideas coming!

8yr ago

Corilla

Maker

A quick video update from downunder: https://www.bonjoro.com/g/tuKd8_...

8yr ago

True Stories

Hunter

Hey David and Nathan, This quote really grabbed my attention - "Corilla is the new technical writing." My question is how and who are you delivering technical writing to?

8yr ago

Corilla

Maker

@stringstory Great question. The kind of technical writing that inspired Corilla originally was the kind we were doing at Red Hat. When I joined we were still hand-coding DocBook XML, compiling with Publican and shipping RPMs. It's the kind of thing some corporations are still doing to create these monolithic narrative "books" for customer documentation. It's slow, expensive and nobody really cares about the customer experience. We built the PressGang CCMS at Red Hat to solve those workflow problems, and over the next few years of speaking about this at technical writing conferences I kept hearing a lot of "me too" from other agitated content teams. But then not just the enterprise teams - we started to hear this from the dev community, and we realised how common this problem has become. It struck me as wasteful that we were all standing up our own solutions - grab an editor, some version control, user accounts, etc. The cost of maintenance is incredible when you think of the dev time going into it. But that's the easy part. The shifting trends of documentation mean it's just not enough to dump a "user manual" with each major release. Teams need to be able to write modular content quickly, with realtime collaboration across the organisation. Then they need to be able to access the existing content through a common and version controlled repository, and finally have the ability to push this to all the multiple outputs that the company requires. One of the areas I think technical writing has failed to deliver is in the "M" part of CMS. At the moment it basically doesn't exist. A wiki is where good content goes to die. It's a nightmare to maintain, as I learned at Red Hat when I took over the MRG Grid docs suite - a product used by the CERN project at the time. Maintaining that was intense, and working closely with our beta community on maintenance automation we've heard how common this issue is. Early days, definitely something we're working on with the wider community - and not just technical writers but the developer community building and maintaining this infra as well.

8yr ago

True Stories

Hunter

@davedri Thanks for sharing a deep dive with us. I beginning to understand why documentation is key to the success of a business, especially for scale.

8yr ago

Footnote

@stringstory @davedri Great insight.

5yr ago

SlidesUp API

Technical writing, especially as a designer has been a tough one to deal with. At my last job, we used Confluence for internal docs and published a static site from GitHub for external docs. That was just for the design + product + engineering teams. We also had dedicated technical writers, technical sales people, etc. They had their own set of tools. One problem we had was keeping everyone in sync with the changes. How might you enable conversations with Corilla?

8yr ago

Corilla

Maker

@kunalslab I feel you! Although in itself, multiple tools across an organisation aren't a bad thing, it becomes a mask for enormous opportunity cost when the marketing team, the support team, the sales team and the technical writers are all authoring their own content in their own workflows. This is something we think a lot about, and it's a trend we're already seeing inside of Corilla. Our technical writing community started as beta users, became advocates in their organisation, got their developers hooked on the ease of collaborative Markdown in the same version controlled environment as the writers, and then... the marketing teams took notice. Most of us on the dev side of things have used some form of VCS for years (e.g. I still have "svn up, svn st, svn up, svn st" PTSD!), but making designers and marketers use GitHub is noble in its intentions, but it's not the kind of intuitive workflow that actually inspires highly active use. So we weren't too surprised when we saw beta users from non-technical marketing teams using Corilla as a "staging ground" for their "approved" design and marketing assets. We made VCS easy. The challenge is how we, as you rightly point out, enable the conversation around them. I have a personal interest in a Slack bot for Corilla (@nathan404 isn't a fan 😭) that would at least lower a few more barriers between dominant communication patterns and the exposure/engagement of content in the repo. But beyond that we're open to ideas. Let's say we make the content discovery super effective (and I can sense our friends from Algolia reading this right now!), and nail the user privs (in a way that Confluence really hasn't)... what would help facilitate the conversation around that content?

8yr ago

SlidesUp API

@davedri that would certainly help. Some way to discover and follow relevant types of content + conversation would be my Holy Grail. Privacy could be just as simple as internal vs. external for now. I jumped to a Slack integration as a solution in my head at first too. Curious—why does @nathan404 think that's not a good idea?

8yr ago

Corilla

Maker

@kunalslab I think it's because @nathan404 doesn't like me having fun 😤 That and how we run our engineering and product pipelines. We all come from an enterprise background, but have all worked in or founded startups. Which means we've seen the damage a rogue CEO can have on jamming features in or demanding engineering ships whatever is shiny that week. At the moment we've got some major updates to the documentation portal, our import and export API, editorial tooling, team reporting and advanced analysis, etc. The Slack bot is in our Kanban's Triage column, but it doesn't make it through the weekly stack rank when we negotiate in the Backlog. As a company we're super transparent with our users both how we work and what we're working on. And I can say I've just not being able to justify the Slackbot as a focus just yet, but I'm tempted to do a little weekend hackathon personally and it would make sense to open source it (with Corilla as just one of the API options). If that sounds interesting to anyone reading, I'd be happy to make a little bounty or work on it collaboratively (again, that Red Hat and community DNA is at our core).

8yr ago

SlidesUp API

@davedri @nathan404 thanks for the insights into this! I like your style :)

8yr ago

Corilla

Maker

Thanks @kunalslab. @davedri covered it pretty well but I just wanted to my thoughts as well. For me it really comes down to focus, and I believe for small teams that focus is incredibly important. We have lots of really fun and interesting ideas (some even a little bit crazy 😉) in the pipeline and the hardest bit is working out what we should focus on. It's not that I'm against the idea of Slack integration (or other integrations), but that there are other core features that we need to focus on for the time being. We spend a lot of time in Slack and I must admit there are times that I wish we had Slack integration (don't tell David I just admitted that).

8yr ago