Why we built a public shipping log
We have been moving fast since March and none of it was visible to anyone outside the team. Here is the thinking behind the /ship log and how we plan to keep it honest.
Jack Luo
Founder, Agent School
There is a version of building in public that is mostly performance. Founders tweet about their revenue, post screenshots of their dashboards, and frame every setback as a lesson with a tidy resolution. It is optimized for engagement, not honesty.
That is not what we wanted to build.
We started working on Rolo in early March. Since then we have shipped a working product, a full marketing site, a mobile companion app, a billing system, a notification engine, and a lot of things in between. None of that was visible to anyone who was not in the repository with us. And invisibility at an early stage is a real problem, not just a marketing problem. If you are asking people to trust a product that is still finding its shape, the least you can do is show them that you are actually moving.
The problem with most changelogs
Most product changelogs are written for users who already exist. They announce features to people who are waiting for them. They are reactive documentation, not a signal of momentum.
We wanted something different. We wanted a record of the actual work: what shipped, what the thinking was behind it, what the grind looked like on a normal week. Not just the big launches, but the infrastructure weeks and the polish stretches that make the product feel trustworthy over time.
We also wanted it to be retroactive from the start. Most changelogs feel like they started last month. Ours goes back to March 2 because the work goes back to March 2, and the full arc of what has been built deserves to be readable in one place.
How it works
The /ship log is a public page at rolo.agentschool.io/ship. Every entry has a date, a title, a short summary, a set of highlights explaining what shipped and why, and a few hashtags for context.
The content lives in a JSON file in the repository. A validated loader reads and sorts the entries before the page renders. This means the page is a static server component with no CMS dependency, and it means a weekly draft generation script can update the content without touching any route code.
The draft generator is a repo script that gathers recent git commits and planning artifacts, produces a structured review document, and asks us to rewrite it into public-safe product language before anything goes live. The automation handles the sourcing. The judgment about what is actually worth publishing stays with us.
What honest shipping looks like
Two updates a week is the target. Not always achievable, and that is fine. Some weeks are full of visible product progress. Some weeks are infrastructure, tooling, and the less glamorous work that makes future shipping possible. We want both to show up in the record, described accurately for what they were.
The bar for inclusion is simple: if you were following Rolo and this week's work would change your understanding of where the product is going, it belongs in the log. If it would not, it probably does not.
We are not trying to manufacture momentum. We are trying to make the momentum we already have visible.
The /ship log is live now. If you want to see what we have been building since March, it is all there.
Want to try Rolo?
Join the waitlist and be among the first to use Rolo.