Product updates and release notes, on a site of their own
You ship the product, and you are also the one who explains what changed.
Free to start, no card. You can export your posts at any time, on every plan.
A new version just went out, and the users who care want to know what changed. A store listing has no room for it, a social post leaves the feed within a day, and a changelog inside the app only reaches people who already opened it.
Release notes need a place on the open web: one address per release, found months later by someone searching for the feature, and an email to the people who asked for one.
Typoza has no changelog module. It has posts, categories, tags and a newsletter, which is what a release-notes blog is made of.
What you need
One page per release, at an address that lasts
Each post has its own address, fixed at its first publication. Six months later, the link in a support reply still opens the right release.
An email when you publish
Switch the Letter on, and publishing a post sends it: each subscriber gets it right away or in a daily or weekly digest, at the pace they chose. An announcement that is not a post can go out as a separate message, within your plan's daily limit.
An editor that can show code
The editor has code blocks with a tab per file, spec sheets for what changed, and callouts in four tones for the breaking changes. Markdown shortcuts work as you type.
Categories that separate the noise
Put releases in one category, longer posts in another, incidents in a third. Each category has its own page, which a reader who only wants the release notes can bookmark.
A site that is not your product
Your workspace runs on its own subdomain, or on your domain with a paid plan. It shares no deploy with your app, stays up when your app goes down, and a post needs no build.
What Typoza does not do
Better to read it here than to find out after three posts. If one of these is a dealbreaker for you, do not sign up.
- Readers cannot follow a single category. The RSS, Atom and JSON feeds and the Letter carry everything the workspace publishes.
- Nothing reads your repository. You write each note by hand: no tag, commit range or pull request turns into a post.
- No widget for inside your app. Your own code can read the JSON feed and show the latest notes.
- No status page. Uptime history and on-call alerts belong to a product built for them.
- No link between comments and your bug tracker. Readers can reply under a release note, and bug reports still go through the tracker you use.
- No versioned documentation. A post records one moment; docs with a v1 and a v2 need a documentation tool.
The post you keep putting off
Write its first paragraph today. The post stays a draft until you publish it, and no reader sees it before then.
Free to start, no card. You can export your posts at any time, on every plan.
The other use cases
- Keep a personal blog without maintaining a website
- Freelancers: show clients what you know before the first call
- The company blog, published by the people who write it
- Your bylines, kept at an address you own
- A travel journal that outlasts the feed
- Publishing as a group, each writer under their own byline