The last weeks of the Corilla beta

Corilla is preparing to come out of beta. That sounds exciting — but what exactly does that mean?

In purely technical terms there’s just a couple of tickets between us and the Generally Available release. Given we’re a SaaS startup that ships weekly builds, maybe the GA terminology of our enterprise software background is a little redundant. But the significance of releasing the paid accounts is one that reflects the importance we place on Corilla’s greatest asset.

Our community.

Since we launched the beta we’ve had the pleasure of talking to over 1000 teams. Recently I’ve been asking a new question though. And one that’s probably the hardest question to ask. Pricing!

A new question

Like any startup we run these numbers from different angles and different models. What we found we enjoyed the most was simply being open with our users about the search for a balance between user value and the resources for the company to grow.

The feedback has been amazing.

We’ve learned that the content industry is fatigued with startups promising the world and then disappearing with their data. Or those taking the headline funding rounds that inevitably result in the company either jacking up prices to appease investor demands, or flaming out without a sustainable business model.

Let’s not even talk about the legacy publishing companies with complicated product lines that looks and even smells like the 1990’s era of software development.

We can (and must) do better than this.

Finding value

When I look back at Corilla’s beta release, I’m torn between being blown away by how far the team and community has come, and how much we have left to do. Then I’m blown away by just how unique Corilla is as a product.

And there lies the difficulty of pricing.

To help us understand the value side of the equation, we took a step back with our users to appreciate exactly what we’ve built together. And it’s kind of amazing…

1. A blazing fast Markdown editor

Corilla began as a collaborative editor with a unique method of managing content libraries across teams. Having written a number of books at Red Hat using a mix of DocBook XML markup and DITA methodologies, I’d simply wanted to find a faster way to author modular and reusable content.

We built Corilla’s editor to be blazing fast 🔥 and with minimal distraction — allowing an entire team to collaboratively author in Markdown at the same time. We loved it and so did the early adopters, some calling it “the new IDE for technical writing”.

2. Topics and collections making reusable content easy

Topics to collections to… anywhere you want to publishing them.

Why do we have to open files to copy and paste content from one document to another?

Why can’t we combine multiple pieces of content on-demand without then having duplicates to maintain?

Think of the actual millions of hours wasted each year as teams dig through filesystems and cloud drives, hunting documents to copy and paste bits and pieces of information that could simply be collected and published together in dynamic collections.

Taking inspiration from the topic-based authoring methodology that we already use in technical writing, we built exactly that. And the workflow is incredible.

Just create your topics like you would any other documentation and let Corilla store them in an internal repository. When you need them, throw them into a collection and publish or export as required.

3. A universal content repository with version control

I used to sit on my command line punching in the svn stand svn up OCD of any typical Subversion user. I’d watch as a swirl of DocBook XML files flew into the loving embrace of version control.

But even then I knew I was burning up my actual writing time on pointless administrative tasks. If Google themselves practice trunk-based development, why were we all still worrying about where to commit and pull files? Who has time for “folders” of source content when all that matters is the end user experience in consuming that knowledge?

Corilla’s versioning is a biased design that defends the writer’s right to spend their time on actually writing. We worry about the tags, filters, search and metadata so you don’t have to.

4. A documentation portal to publish and host your content

We then built a proof-of-concept documentation portal to show how easy it is to publish directly from Corilla. The beta users began using this in production (!!!), so we shipped an update to the portal design. And so effectively added both (unlimited) documentation hosting and internal documentation repositories.

Oh yeah, and we added it for free. How much are you paying that help desk company for a content portal again? Does it even have a sidebar?

5. Media repository

If any of the above has gotten you as excited as it has our early users... wait until you see what we’re doing with our vision of “the Github of content teams”... 💯

Finding the value of a streamlined workflow

What I find interesting about Corilla as a technical writer myself is just how effective it is in bundling the writing and publishing tasks into an intuitive workflow.

The recent acquisition of Trello by Atlassian sums up the same movement we responded to ourselves. JIRA had all the features, but Trello had the workflow.

And in a similar sense, Corilla is to Confluence what Trello is the JIRA — a movement for UX-driven simplicity that puts increasing value in helping more people get things done with a superior workflow, and carefully saying “no” to feature creep for the sake of it.

Which brings us back to our next steps in coming out of beta and into the market. And a reminder that we’re on a journey here — not just as a company but as a community.

If you’ve been a part of that community so far, thank you so much. And if you would like to check out Corilla this is a great time to do so. All beta users will have a special subscription option available when we launch, so I suggest you start writing with Corilla now.