Why We're Building UpdateTinus

Launch edition: this founding note is published during UpdateTinus's early-access preview; plans and features described here may change before general availability.

Every product team we have ever admired shares a quiet habit: they tell people what they have been working on. Not in a press release, not in a dense list of ticket numbers, but in a voice that sounds like a person who is genuinely excited to share something. We started UpdateTinus because we believe that habit should be easy for every maker, not just the teams with a dedicated writer and a designer on standby.

The problem we kept running into

If you have shipped software, you probably recognise this moment. A feature is finally done. It took weeks. It solves a real problem. And then the announcement is an afterthought: a hurried line in a changelog nobody visits, a message in a team chat, maybe a social post if someone remembers. The people who asked for the feature may never learn it exists.

Meanwhile, the tools for writing updates are scattered. Drafts live in one place, screenshots in another, feedback in a third, and the roadmap in a slide deck that was last updated two quarters ago. Each piece is reasonable on its own. Together they make communicating progress feel like a chore.

We think that is backwards. Shipping is the most exciting part of building a product, and telling people about it should feel like part of the celebration.

What we believe

• Updates are a form of respect. Users give you their time and trust. Telling them clearly what changed respects both.
• Joy is a feature. A release note can be warm, visual and even a little playful without losing clarity.
• Feedback should go somewhere. When someone takes the time to suggest an idea, they deserve to see what happens to it.
• Honesty beats hype. Saying "this is in beta" or "we got this wrong" builds more trust than polished claims.

What UpdateTinus is

UpdateTinus brings the whole loop of product communication into one friendly place:

1. Release notes and changelogs drafted on a visual canvas, with tags, versions and media galleries.
2. In-app beacon widgets that let users discover what is new without leaving your product, complete with emoji reactions.
3. Feedback boards where users can share ideas and vote on what matters to them.
4. Public and private roadmaps that show what is planned, in progress and shipped, linked back to the feedback that inspired them.

Around that core, we are building integrations so updates can flow from the tools where work already happens, such as issue trackers and code repositories, and out to the places where people already gather, such as team chats and community servers. Those integrations depend on third-party services and are in beta, and we will always be clear about that.

Why now, and why us

Products ship faster than ever. Continuous deployment means improvements arrive daily, but users often experience that as constant, unexplained change. The faster you ship, the more important it becomes to explain what you shipped. We want to make that explanation as lightweight as the deploy itself.

We are a small team of makers who have written plenty of rushed changelogs ourselves. We know the guilt of a feature nobody heard about, and the delight of a user replying "I have wanted this for months." UpdateTinus is our attempt to create more of the second feeling and less of the first.

We want the moment after you ship to feel like opening a window, not filing a report.

Where we are today

UpdateTinus is in early access. That means nothing is generally available yet, features are still changing, and some parts are rough around the edges. We do not have a long list of customers to point to, and we are not going to pretend otherwise. What we have is a clear idea, a working preview, and a growing set of conversations with makers who care about communicating well.

Every release note you read on this site is written in that spirit. Each one is marked as a launch edition, because the details may change as we learn. When we share numbers, we will tell you whether they are measured or simply illustrative.

How we will build

• In the open. We will publish our own changelog with UpdateTinus, including the things that did not go as planned.
• With makers. Our feedback board is where early-access teams shape priorities, and we read every post.
• Carefully. Privacy, accessibility and calm defaults matter more to us than shipping the longest feature list.
• Joyfully. If using UpdateTinus ever feels like a chore, we have made a mistake, and we want to hear about it.

An invitation

If you build products and you have ever wished your updates landed better, we would love for you to join us. Try the preview, write a release note, add a beacon to a test project, or simply tell us how your team communicates changes today. The most useful thing you can share is an honest story about what is hard.

We are building UpdateTinus for the moment you press ship and want the world to know. Thank you for being here at the very beginning.

Warmly,

The UpdateTinus team