Agent Dashboard becomes Build Studio — and goes open source

The biggest thing that shipped since the last entry is not one of the products. It is the tool that builds them.

Agent Dashboard is now Build Studio, and it is available as open source. The repository is live at github.com/My-Next-Studio/build-studio.

The old name described the screen. The new one describes the job. Build Studio is mission control for the way I run My Next Studio: a set of specialised AI agents moving a product through small PRDs, review, implementation, QA, security checks, and the human approval gates in between. The dashboard is still there, but the useful part is the system around it — the workflows, role definitions, project scaffolding, isolated worktrees, and the record of why each change exists.

I have written about that workflow here since the Journal started. Where Agent Dashboard came from covered the first web version and the move to Electron. Agentic engineering with Agent Dashboard covered what changed when the agents worked against written specs instead of interpolating from prompts. Build Studio is the point where that internal tool becomes something other people can run, inspect, change, and argue with.

The public release includes the multi-project hub, new-project and existing-project onboarding, review and execution workflows, the bundled agent roles, a CLI, and the macOS Electron app. It expects Node, Claude Code, tmux, and git; the repository is Apache 2.0 licensed. Since the first public commit, I have also added a live agent terminal, a lean bugfix workflow, a support-triage view, knowledge manifests, automatic recovery when an agent process dies, and an evidence-gated owner-verification step. Apparently the way to celebrate publishing a tool is to immediately keep working on it.

If you try Build Studio and something does not work, please tell me. The same goes for rough edges, missing documentation, workflow ideas, or feedback that amounts to "I would never build software this way." Email [email protected], or reach me on the new X account @MyNextStudio. And if you use it to build something, I would genuinely like to hear what.

Elsewhere in the studio

Build Studio was the headline, but it was not the only repository moving.

Välkomna ships guest photo albums

The biggest live product change is at välkomna.se: every event can now have its own shared guest photo album.

The basic problem is familiar: after an event, the photos are spread across the guests' phones. The album adds a collection and sharing path to the event page that is already there, rather than making the host set up a second service.

The flow is deliberately simple:

1. The host enables the album for the event.
2. Guests open the event page from its link or QR code.
3. They upload photos from the phone browser — no app and no login.
4. The photos collect in the event's shared album.
5. The host can approve, reject, or remove them from Mina sidor.

The host chooses between reviewing photos before they appear or letting uploads show immediately. Review-first is the default. Guests can contribute up to 2,000 photos per event, browse the shared gallery, and open the full images in a lightbox. The host gets the same gallery plus a moderation queue and bulk approval.

The initial product decision was whether the album should be a separate paid add-on. It is not: v1 is included in the existing event price. That keeps the implementation inside the current event lifecycle — the same host account, event slug, expiry date, and management surface — and gives me a chance to see how people use it before inventing another pricing tier.

The less visible half took at least as much care as the gallery. Guest photos are resized to WebP, stripped of EXIF metadata, stored in R2, and tied to the event's retention lifecycle. When the event expires, the database rows and objects are deleted with it. Uploaders see a consent notice, public API responses use an explicit field allowlist, and hosts remain in control of what is visible.

The event HTML and album storage paths also picked up reproducible versioning, backup, and rollback drills. Anonymous photo upload widened the abuse and failure surface: body-size and pixel-count limits happen before image processing, uploads are rate-limited, and the per-event cap bounds storage. None of that is visible in the gallery, but it is most of what separates a demo album from one I am comfortable running live.

The photo album is live now. This is the first time it has appeared in the Journal; most of it landed while the recent entries were talking about DeskRhythm and Fazon.

Fazon learns to read the food in front of it

Fazon has had the busiest July in raw commits, though it is still well away from release. The active-phase coaching loop picked up forecast bands, learned-TDEE carryover, a pay-at-confirm onboarding flow, waist measurements at phase boundaries, meal reminders, and a six-month step baseline that sets a more realistic movement floor.

The more interesting experiment happened this week: using the camera for food entry. One path reads a nutrition label and prefills the values for confirmation. The other uses Apple's on-device Foundation Models on iOS 27 to return several possible matches from a food photo instead of pretending the first guess is certainly right.

That distinction matters. A camera feature can save typing without being allowed to invent certainty. The current shape is deliberately assistive: scan, inspect, correct, then save. The early food-photo corpus reached 93.3% top-three accuracy, which is good enough to keep building and nowhere near good enough to remove the confirmation screen.

DeskRhythm moves from beta launch to launch work

DeskRhythm's public TestFlight beta is still running. Since the last entry, the app gained its StoreKit entitlement gate, trial and paywall surfaces, and the App Store provisioning work around them. The product page now has a short feature-tour video and a tighter /app presentation, and the blog published a piece on why a desk timer does not need your data.

Most of that is launch work rather than new timer behaviour. That is where the project should be: the core rhythm is stable enough that the work has shifted toward explaining it, charging for it, and making sure both fail cleanly.

My Next finishes the twenty-language pass

The last journal entry said the My Next family was going from two languages to twenty. The remaining localisation commits landed immediately afterward: Dutch, Italian, Danish, Norwegian, Finnish, Polish, Japanese, Korean, both Chinese variants, and Brazilian Portuguese, plus fixes to translated default lists, app shortcuts, onboarding copy, and subscription labels.

Version 1.2 now carries that localisation expansion. The apps themselves were otherwise quiet, which is intentional. Twenty languages create enough surface area to watch before adding another feature.

Sickla tunneln and Skrivhjälp were quiet too. Not every repository needs a paragraph pretending otherwise.

What's next

Build Studio is public, but "public" is not the same as finished. The immediate work is making the first-run path understandable to someone who did not build the workflow, tightening the documentation where real use exposes assumptions, and deciding which internal conventions deserve to become configurable instead of merely documented.

If you take it for a spin: open an issue on GitHub, email [email protected], or find me at @MyNextStudio. Bugs are useful. Feedback is useful. Seeing what somebody else builds with it would be the best signal of all.