Public Changelog

You've done something incredible: you've built a fully working SaaS from scratch. Real features. A database. Authentication. Third-party integrations. API integrations. Payments. This is a major milestone, and it's just the beginning. Now it's time to celebrate what you've built and establish a practice of documenting your progress through a public changelog.

1. Celebrating your achievement

You've Done Something Extraordinary:

Congratulations! You've just built a fully working SaaS from scratch. This isn't a tutorial app or a demo–this is the real thing:

✅ Real features that solve actual problems
✅ Production database (Neon) storing user data
✅ Authentication system (Clerk) protecting your app
✅ Third-party integrations (Stripe, payment processing)
✅ API integrations (webhooks, data syncing)
✅ Payment system with subscriptions and feature gating
✅ Production deployment with security and monitoring

This is a production SaaS that real users can sign up for, pay for, and use.

This Is Just the Beginning:

You've completed the foundation. Now the real journey starts: iterating based on user feedback, adding features users request, fixing bugs they find, and growing your product into something users love and pay for.

Why Document Your Journey:

As you move forward, it's worth keeping a journal of everything that changes and gets published. This is typically done through a changelog–a public record of your progress that:

• Keeps you motivated – seeing progress accumulate is powerful
• Builds trust – transparency shows users you're actively improving
• Creates momentum – regular updates prove you're moving forward
• Attracts users – people follow companies that ship consistently
• Helps recruiting – candidates see your execution culture
• Impresses investors – demonstrates ability to execute

Outcome: You understand the significance of what you've built and why documenting progress matters.

2. Understanding why changelogs matter

The Philosophy Behind Changelogs:

As Karri Saarinen from Linear explains in Startups, Write Changelogs, changelogs serve multiple purposes beyond just documenting changes:

1. Momentum:

"In the early stages of startups, it's important to keep moving and make progress. As Paul Graham says, startups rarely die in mid keystroke but they die because they get demoralized and give up. Having a changelog reminds you each week that the way forward is to keep making something people want."

2. Early Adopters:

"Most startups start with a core group of early adopters. These are people who are excited and willing take a risk of a newly developed software, and likely want to be part of helping to shape the product as well. Fixing things and publicly sharing the new changes and additions shows that you value the user feedback and want to improve the product for them."

3. Culture:

"Weekly changelogs help communicate that the company values execution and shipping things, which is crucial in startups. If you don't ship your work, you are not creating value for users, and increase the value of the company. It can also be a celebratory moment for the team as a whole when team members release their first features and sees the user feedback in real-time."

4. Marketing:

"We have over a thousand people who follow and interact with the changelog updates. They find the progress, design, and other changes inspiring, and sometimes share it with their co-workers or friends, even if they are not Linear users. This spreads the word and leads to more people adopting Linear."

5. Recruiting:

"As the changelog is public, it acts as marketing for potential candidates: things about your culture, the product, and how you make progress. Most of our candidates have followed our changelog posts for a while before applying. Companies that execute fast, while valuing quality and craft, is appealing for many builders. Actions speak louder than words."

6. Investor Relations:

"Likely the majority of angel investors and VCs that I met mentioned they have been following our changelog updates, and have been impressed by the progress. This means that even before talking to them, they already had some sense of how we work, how the product works and how fast we make progress."

Key Takeaway: A changelog isn't just documentation–it's a tool for building momentum, culture, trust, and growth.

Resources:

• Startups, Write Changelogs by Karri Saarinen (Linear) - The philosophy and benefits of maintaining a public changelog
• Linear's Changelog - Real-world example of a well-maintained changelog

Outcome: You understand the deeper value of changelogs beyond just listing features.

3. Building your changelog

The Simple Approach:

Your changelog will use a markdown file. This is the simplest approach for documenting your progress–no database needed, just a markdown file that you update as you ship features.

Entry Structure:

• Date (when shipped)
• Version (optional, e.g., "v1.0", "v1.1")
• Category (New Feature, Bug Fix, Improvement)
• Title (brief, clear)
• Description (what changed, why it matters)

Design Principle:

Keep it simple: date, title, description. No fancy animations. The content matters more than the presentation.

Outcome: You have a working /changelog page with a comprehensive v1.0 entry documenting all your achievements.

4. Maintaining your changelog going forward

Establishing the Practice:

Now that you have a changelog, here's how to maintain it as you ship future updates:

Best Practices (from Linear's experience):

1. Set a schedule:

   • Weekly or bi-weekly cadence
   • Try not to slip – if progress is slow, understand why
   • Pair with your sprint/cycle completion

2. What to include:

   • Feature 1–3 larger changes as highlights
   • Collect all small fixes in one section
   • Focus on things interesting to humans (not database migrations unless they improve UX)
   • Include screenshots or videos when possible

3. Writing style:

   • Rotate writing responsibility (if you have a team)
   • The person who built the feature usually writes the entry
   • Find your voice – technical audiences appreciate details, others may not
   • Keep it human and engaging

4. Share your updates:

   • Post changelog updates to Twitter/X with screenshots
   • Allow newsletter subscriptions (copy changelog content to your newsletter tool (Beehiiv, Substack, etc.))
   • Share in your community channels

How to Update:

Remember:

"So write changelogs. It's an easy and low-effort way to keep the momentum, get new users, recruit, and build investor relationships. All things that help your company to be more successful." – Karri Saarinen, Linear

Resources:

• Linear's Changelog - See their approach
• How to Write Changelogs - Best practices from Linear

Outcome: You understand how to maintain your changelog and have established a practice for documenting future updates.

Congratulations! You've made it through the entire Codex–from setting up your local environment to building a fully functional SaaS with payments, authentication, and everything in between. This is no small feat. You've stuck with it through the ups and downs, the debugging sessions, the feature implementations, and all those moments where things didn't work the first time. You've built something real, something that works, and something you can be proud of. Thank you for your perseverance, your dedication, and for trusting this process. You're not just a learner anymore–you're a builder. Now go ship something amazing. 🚀

– Ben