I think it is an excellent idea, and actually it fits Jaroa unusually well.

What you’re proposing is more than keeping a development diary. It creates a public chronological record of how the project evolves, which is valuable precisely because Jaroa is being built incrementally.

The important distinction I’d make is this:

Each conversation becomes a development journal entry, not necessarily a polished tutorial.

That gives you something much more authentic.

Why I like this approach

Right now, Jaroa has a story:

headless-php-application
        ↓
architectural experiments
        ↓
working frontend/backend separation
        ↓
API boundary
        ↓
Jaroa 1.0
        ↓
future platform

If we document each significant conversation, six months from now you won’t have to remember why something was designed a certain way.

You can go back and see:

  • what we were trying to solve
  • what alternatives we considered
  • what decision we made
  • what code existed at that point
  • what broke
  • how we fixed it
  • why the architecture changed
  • what we deliberately didn’t build yet

That last one is particularly important for an evolving project.

It also gives sanjibsinha.in a different kind of content

Rather than producing generic articles such as:

“How to Build a PHP Application”

you can have a chronological series such as:

Jaroa Development #01
From Headless PHP Application to Jaroa

Jaroa Development #02
Establishing the Frontend Architecture

Jaroa Development #03
Creating the API Boundary

Jaroa Development #04
Separating Frontend and Backend with DDEV

Jaroa Development #05
Jaroa 1.0: The First Repository

Jaroa Development #06
Updating the Jaroa 1.0 README

And each post can link naturally to the previous and next stages.

That creates a development trail rather than a pile of unrelated technical articles.

And there is another advantage

It preserves the thinking.

The final Jaroa documentation will eventually say something like:

“Jaroa uses an independent frontend and backend separated by an API.”

That’s useful.

But the development journal can explain:

“We initially built this as a headless PHP application. During development we discovered that the reusable part wasn’t necessarily the entire application, but the architecture and boundaries around it. That led to the name Jaroa…”

That is much more interesting.

It documents how an architecture becomes an architecture.

I would establish one simple rule

For the Jaroa series:

One conversation = one chronological development record.

But not every conversation needs to become a giant article.

A small conversation like today’s README change could be a relatively short post. A major architectural conversation might become a substantial article.

We can preserve the conversation’s natural development first and then turn it into a readable post afterward.

So the workflow becomes:

Jaroa workshop
      ↓
Conversation
      ↓
Actual implementation
      ↓
Testing
      ↓
Commit
      ↓
Development post
      ↓
Chronological Jaroa history

That is a very good match for the way we’re already working.

And since you’ve now decided this is the documentation strategy going forward, I’ll treat the Jaroa development conversations as a chronological record when we work on them.

In fact, I would eventually put a small “Jaroa Development” label/category on these posts, so the whole journey can be browsed as one continuous series.