Between 4 September and 13 September 2026, we shipped 113 commits across 7 days. Those commits touched 497 files, added 25,778 lines, and removed 1,800. new-Orqestra took 100 of those commits. Life-Race-V2 took 10. NeuraGrowthHTML took 3.
Two books reached their shelves inside that window. The Micro-SaaS GTM Playbook shipped on 10 September as product 187. Model Context Protocol for the One-Person Stack shipped on 11 September as product 188. Both are on KDP in digital and print.
This post is about what that period looked like from inside the studio, and what it revealed about how we decide what to build, what we fix before we ship, and where the system still argues with us.
The decision to write about MCP was not strategic in the way that word usually implies. We had been running MCP tooling inside Orqestra for long enough to have hit the failures that do not appear in the official documentation. Package versions that 404 on npm even when the package itself resolves. Grammar compilers that count properties rather than characters. The kind of thing that only surfaces when you are actually running the stack.
A guide earns its place in the catalogue when the research cost of getting something right is high enough that sharing it is useful to someone else. The MCP space met that bar. The tooling is real, the setup is fiddly, and the people who need it are builders working alone who cannot afford to spend a week on a version pin that turns out not to exist.
Model Context Protocol for the One-Person Stack is product 188. It is a setup guide aimed at developers running a one-person stack. The commits that went into that book's final review round are part of this same ten-day story, and the two things are not separate.
Commit feat(book): verify every printed package version, and audit rules against the book's own examples landed on 11 September. It changed 6 files, added 162 lines, removed 4. The reason for the commit is the part worth keeping.
This was the fourth review round of the book. The scores across the review rubric rose: 7.9 to 8.6, 9.3 to 9.8, 8.7 to 9.0, 6.0 to 7.5. A revision was clearly working. But the two items flagged as blocking were both defects the revision itself had introduced, not holdovers from the previous draft.
An earlier review note had told every template to pin a released package version rather than use a floating tag. The author supplied versions that looked correct. We checked each one against the registry. Nine of the ten printed version pins do not exist. The packages resolve; the specific versions return 404. A reader copying google-calendar-mcp@1.4.0 would get a failure, which is strictly worse than the floating tag it replaced.
A rule that demands precision is only useful if the precise value is real. We caught it before the book shipped. The lesson is that a revision note which tightens a rule also creates a new way to be wrong, and that new way needs its own verification pass. We log the npm 404 pattern separately at https://neuragrowth.co/log/mcp-package-versions-in-npm-can-404-even-when-the-package-exists/ if you have hit the same thing in your own stack.
The studio has a small line of bilingual learning material for children. Readers of this post almost certainly came here through the guides side of the catalogue. But the kids content runs through the same Orqestra pipeline, and a bug in that pipeline is a bug.
On 12 September, commit feat(kids): what belongs in the air may be put in the air changed 3 files, added 124 lines, removed 3. A piece of content for the kolory-003 script asked which object shines in the sky during the day, over an illustration of a sun. The sun was on the floor.
The writer did not make an error. The script language had an anti-levitation rule that refused every prop above the ground line unless it carried a hold or on attribute. The on attribute required a base object underneath. With no valid base in the sky, the system could not place a sun there. So it placed the sun on the floor and put the sky reference in the narration, because that was the only path that passed validation.
The fix added a rule that allows objects to be placed in the air when the content calls for it. 124 lines added. The record does not say how long the system had been generating content with a sun on the floor before someone looked closely enough to see it.
Over the same 10-day window, the operation deep_dive.research cost 12.45 USD, which was 11.4 percent of the total 109.58 USD spent across all operations. It ran 30 times, on claude-sonnet-4-6, averaging 0.415 USD per call.
That share matters for a decision we face repeatedly: how much research depth to buy per book, and when a cheaper call would do the same job. We have written about that model-selection question directly. The post at https://neuragrowth.co/blog/sonnet-vs-opus-on-pdf-critique-when-to-reach-for-which/ covers one instance of it in detail.
What the cost breakdown tells us about how we decide what to build is this: the expensive part of the pipeline is not generation or formatting. It is the research that determines whether a piece of content is worth building in the first place. If that research step is wrong, everything downstream is wrong too. That is why the 30 calls at 12.45 USD show up as a line item we track rather than a background figure.
We do not have a formal process for deciding what goes into the catalogue next. What we have is a set of conditions that tend to produce a book: we have hit a problem repeatedly, the documentation does not cover it, and the solution took long enough to find that it would cost someone else the same time to find it again.
MCP met all three. The npm 404 pattern, the grammar compiler behaviour, the version-pin trap - none of those are in the official docs. They are in our logs, and now they are in the book.
The Micro-SaaS GTM Playbook came from a different starting point. The record does not say what triggered it, so we will not speculate. What the facts say is that it shipped the day before the MCP guide, and both cleared review in the same 10-day window. We shipped it because it was ready.
If you are building something similar and want to understand how the underlying automation holds the operation together, the post at https://neuragrowth.co/blog/how-claude-powers-a-one-person-shop-that-runs-without-you/ describes that directly. The thing to do differently is visible in the version-pin story: when a rule change tightens a requirement, the new requirement needs its own verification pass before it reaches the reader. A review round that raises scores can still introduce defects. The scores are not the check. The check is checking. That applies to the book pipeline, and it applies to the kids content pipeline that was generating sun-on-the-floor illustrations until someone looked closely enough to see it.
Originally published at neuragrowth.co. NeuraGrowth is a one-person digital-products studio; this is the log of what its pipeline does and where it breaks.