The project management question came back while I was turning a client call into a structured delivery plan. The source material was already text: a transcript, extracted requirements, screen notes, feature groups, estimates, risks, open questions, and implementation slices. The useful output was not naturally becoming a board. It was becoming a set of structured documents. If the work is already being clarified in text files, what exactly do I gain by pushing it into a SaaS project management tool?
Documentation Already Moved This Way
A README can change with the feature it explains. An architecture decision record can sit beside the code it constrained. Deployment notes, migration notes, changelogs, runbooks, API examples, and configuration notes can be reviewed with the work that made them necessary.
Documentation outside the delivery system drifts. A wiki page can be correct on Monday and quietly false six months later. A document folder can hold a useful decision, but if nobody sees it during implementation, review, or deployment, the decision becomes archaeology.
Git made these files versioned, reviewable, searchable, and publishable. More importantly, it put them inside the same change process as the work they describe.
The emergence of CLAUDE.md and AGENTS.md files made the pattern more explicit. These files are not end-user documentation. They are instructions for the delivery environment itself: how to run the project, what conventions matter, which commands are safe, and what an agent should know before touching the code.
The Branch Was Already the Unit
I was already moving the delivery system in that direction. For this rebuild, I wanted implementation branches to have automated review workflows without manual infrastructure intervention. A branch should carry the work far enough that review, verification, and environment setup can be driven from the branch itself, not from a separate checklist in my head.
Once the branch becomes the unit of delivery, adding project management documents to it is consistent. Scope boundaries, requirements, slice plans, acceptance criteria, review notes, status, publishing order, and the reason one item is next instead of another all belong with the work they control.
That matters more in AI-assisted work because these documents are not only for people. A slice plan can be read by me, committed to Git, reviewed in a diff, and then handed to an AI agent as implementation context. A review note can become the criterion for the next pass. A status file can tell a person, or an agent, what should happen next and why.
The Board Was Never The Hard Part
I have used enough project management products to know the recurring setup tax. Pick a tool. Model the workflow. Decide the statuses. Configure the fields. Work out whether the client can tolerate the interface. Check the API. Then copy the useful detail into cards, often in a flatter and less precise form than the source material already had.
For a large team, that translation may still be worth it. For this project shape, the equation is different: one main client contact, one developer, a large rebuild, and source material that already starts as transcripts, notes, estimates, plans, and review artifacts.
The board only becomes useful after the project has answered the questions underneath each card. What is actually in scope? What is explicitly out? Which requirement depends on an unresolved decision? Which part is implementation, which part is data cleanup, which part is infrastructure, and which part needs client clarification? What is small enough to give to an AI agent without creating a review problem later?
The File Has To Produce The Next Action
This publishing system is a small example. The repo has a state file, a publishing ledger, an AI sequence, a hosting sequence, and a ratio rule. When I ask what should go out next, the answer is not picked from whichever draft happens to be ready. It is derived from the files.
On 13 July, the ledger said the last confirmed post was hosting, on 10 July. The running count was five AI/software posts and two hosting posts, with no AI post since the last hosting one. That ruled out another hosting post on the personal profile. The next unlocked AI item was jd:04, so the next action was to draft or publish that. A hosting post may exist as an idea, but the personal LinkedIn ratio says the next main-feed post should be AI.
Where This Leaves The PM Tool
If the useful material is already in transcripts, estimates, requirements, slice plans, review notes, commits, and status files, then copying a simplified version into a separate tool may be the extra step.
For this kind of one-developer, AI-assisted rebuild, I want the project management documents in the codebase for the same reason I want technical documentation there: so they can be checked against reality while the work is happening. I will judge the system by whether the project files carry enough state, order, and evidence for the next person or agent to act from them, review against them, update them, and produce the next correct action.