Shipping a Changelog Every Friday for More Than 4 Years

Last week we hit send on our 222nd consecutive weekly changelog.

Our changelog is one of the most popular things we do. We average around 115K readers per week (that we know about), with an open rate that sometimes touches 50% (excellent), and we’ve never missed a week.

We never thought much about the streak until this message hit our DMs a while back:

Hey, long time fan and especially a long time fan of how you all have consistently published a changelog for (checks calendar) 3+ years? I'm curious how you've made the weekly changelog work with you engineering team. Is it a weekly call-out type thing? Are engineers working on things with that weekly changelog in mind?

Ok! We thought. It seems like people want to know about this.

So we wrote up a technical post about our feature-to-changelog lifecycle. That’s what you’re reading now.

Let’s jump into it.

The Railway Changelog has been published weekly for more than 200 weeks

If you just want to know the mechanics of how we write the changelog, there’s no need to read ahead.

This is how it’s done:

• We have a #changelog channel in our internal comms
• We wrote an automation (a bot running a cron) that opens a new changelog thread at the beginning of each week
• When an engineer finishes a new user-facing feature, they push it to the thread. This could be a Product Engineer, Infrastructure Engineer, Community Engineer, Support Engineer, Solutions Engineer — you name it
• The changelog DRI (directly responsible individual) for the week collects the notes, asks questions, digs into the code, looks for examples, generates relevant assets like gifs or images, and crafts a story for the weekly post
• We use Notion to write, edit, and publish. To get Notion to work as a CMS, we wrote some software to interface with the Notion API. We parse body content and transliterate each content type to html. Since each page is a database with a number of properties, we parse each of the database properties like description, slug, date, author, etc and plug them in to the page metadata or route or byline, and so forth. We use NextJS ISR (incremental static regeneration) to rebuild the page every 15 mins. When the published checkbox is checked, we pull in the published page to build
• We use Cloudinary as a CDN for things like the OG image and for larger images and videos as Cloudinary far outperforms Notion when it comes to CDN tasks
• We also cut assets using a pair of nifty tools — Screen Studio for animated screen recordings and CleanShot for static images. For any graphics work, we use Figma
• When we publish, the post appears on the changelog page. We wrote a custom bit of software to provide authenticated Railway admins (the same authentication path as in the main app) the ability to test-send the email, and then to send the email to the entire (opted-in) production user base. The email is sent via Customer.io’s API-triggered broadcast feature
• We then workshop the social posts in a comms channel called #social-staging and finally we blast out the post to social channels

So … can you guess the hardest part of all this?

Yep — it’s the social engineering bit. The hard part is to create that right environment internally to promote eager push-based updates from the team.

To me this is the most interesting part of the chain because it’s the “messy middle” stuff I wish I knew years ago.

This is how we create that environment.

We prefer automations over process whenever possible — while a good automation will result in the outcome we want, a good process will result in … more process.

It might seem like solving the push/pull problem is a notable exception, right? Ask the engineers to push their feature updates to the changelog channel…

Yeah, that doesn’t work.

It doesn’t work because this is a systems design problem not a process problem.

To my eyes, we’ve solved the push/pull problem a number of ways:

• We hire “highly technical, highly autonomous, and highly driven” people
• We don’t do meetings outside of Mon + Fri and instead update each other asynchronously via Daily Wraps … this builds the muscle for emitting eagerly
• We have a crystal clear internal roadmap that we stack-rank for the quarter ahead of time … so it’s always clear what people are working on
• Project owners emit updates in a project channel as well as in #progress-pics, which doubles as a the dopamine superhighway of our company (If something cool happens in #progress-pics, everyone is talking about it)

When it’s time to release the feature, not only is there a longitudinal history of where the request came from (linked to the ticket with a nifty piece of software we wrote to interface with the Linear API) and why it’s important (every feature has an RFC), but there’s also a fleet of soup-tasters standing by to use the feature.

We then roll it out to Priority Boarding, pop it in the changelog, and ask for more feedback.

What this gives us is an environment where each person does not need to be managed but rather shares their vision, progress, and latest ships eagerly with the rest of the team.

But this doesn’t just relate to sharing internally, it’s about sharing with the customer — our product team has an insatiable thirst for user feedback.

When we bring new features to bear on our product in the changelog, it’s highly likely they were first requested by users.

We have a couple of mechanisms for collecting user feedback:

• We operate a feedback and direct support forum called Help Station (it’s home-rolled to give us way, way more control than available with off-the-shelf tools)
• We send (very effective) churn feedback emails (Hint: Short and sweet, 2 small sentences max.)
• We send (very effective) white-glove solutions emails with direct booking links
• We maintain a Discord community of 20K+ users
• We’re active on Twitter with 20K+ followers
• We’re active on Slack with our Teams users

… basically any way we can get your feedback as a user, we’ll take it and ask for more.

We rely heavily on user feedback to set the direction for our product

And all this feedback is routed directly to our internal comms via webhooks and various automation tools. So throughout the quarter we’re getting a firehose of comments from users, in the users’ own words, explaining what they need, where they’re getting stuck, why they churned, and so forth.

These comments impact our project planning heavily.

We’re happy with the story so far, but there’s a lot more ground to cover.

To complete the full picture of the conjoined triangles of success that we’re after, we need to better productize new SKUs (coming soon), publish a public roadmap (coming even sooner), start airdropping features to users automatically based on need, and start serving in-app roadmap updates and notifications.

We’re running full-speed toward a product development engine that wastes as little heat as possible.

Along the way we’ll automate like crazy and try never to miss a future changelog.

Think we can we do it better?

We’d love (you guessed it) to hear from you.

Drop us a line and tell us what you think.