Weekly Dev Call Updates — Building BrainDrive in Public

BrainDrive Development
,
21

August 31, 2026 Update

Dave W was out this week, so Dave J ran the call solo: a walkthrough of BrainDrive as it stands today, where Resume Builder landed after Friday’s review, and the sequence he is working through while Dave is away.

Key Highlights

  • Resume Builder is 90 to 95 percent there. The interface was rebuilt from a structured form to “just talk to it,” and Friday’s review left a short list of visual cleanups (fonts and similar) rather than functional gaps.
  • Every miss becomes a process fix. The form-vs-conversation detour was traced back to where the interview and docs failed to steer the AI, and the fix is an explicit “read the style guide before any UX decision” step in the build.
  • A second test app, Brief Builder, is being built alongside Resume Builder to prove the app infrastructure is reproducible and not a one-off. A third may follow.
  • Neon to self-hosted Postgres is finished and documented in the Library so the next infrastructure change can lean on it.
  • This week’s targets: Internet Search capability, app lifecycle (install, update, uninstall), then Job Discovery.

What We Covered

BrainDrive today, from the top: The walkthrough covered the parts owners control: model selection (BrainDrive Models, OpenRouter, or your own local model by IP), GitHub-backed backups with full version history, and migration between a local copy and a hosted one in either direction. The four default pages (Finance, Fitness, Career, Relationships) all run on the same pattern: an interview, a spec, and a build plan that hands you achievable steps instead of an impossible task. Projects extend that pattern to anything you want, from ESP32 hobby inventory to a small art business.

Resume Builder and the “just talk to it” lesson: Dave J built a very structured form; Dave W wanted a conversation. The redesign is done and the app now runs through the normal chat interface. The interesting part was the post-mortem: where in the interview or the Library did the direction get missed, and what needs to be hard-targeted in the docs so the AI reads the style rules before making UX choices. That is the compounding loop we keep talking about, applied to our own factory.

Less code, more markdown: Most of this week’s app work was on the data behind the apps, the interview flow and spec markdowns, rather than code. The goal is to lean on the model’s intelligence and keep the app layer thin, which is why Brief Builder exists as a second proof that the infrastructure generalizes.

How the factory works: The business side produces a product spec, user stories, and an evaluation plan. The tech side answers with a work spec, an implementation plan, and a test plan, with syntax checks and small tests at each milestone. Every decision and the conversation behind it is recorded, so when a fork comes up, the history usually already points the way.

App lifecycle and capabilities: Right now the app assistants live in their own environment inside BrainDrive so the foundation can be iterated quickly. The next step is making each app its own entity with its own repo and location, so install, update (a flashing button, one click), and uninstall are seamless. Internet Search will be the first capability, meaning nothing you use directly, but something apps and projects can draw on. SearXNG is the likely first provider, with other search capabilities open to anyone who wants to build one.

What’s Next

Get Internet Search working and tested on its own, then wire it into Job Discovery so a job search populates inside BrainDrive and you can say “tailor my resume for this one.” Application Preparation (resume plus cover letter against a specific listing) follows. Dave J does not expect to get past that point before Dave W is back Wednesday, but the remaining steps in this sequence are few, and after it the focus shifts to more apps and assistants. Foundation and capability contract docs get updated as each piece lands so any developer, human or AI, can build an app from them.

Watch the full recording:

22

September 7, 2026 Update

Labor Day call, both Daves on, and the first one where Dave W’s AI sat in live to run the agenda. Two hours, mostly decisions: freezing the first Resume Builder candidate for a formal evaluation run, clearing a backlog of documentation pull requests, and settling how the two of us test.

Key Highlights

  • Resume Builder is being frozen for its first formal evaluation run. The candidate branch is named, the last fix set is agreed, and Dave J calls the freeze tonight. Dave W’s evaluation starts on that exact revision.
  • Eight documentation PRs merged on the call, including the Model Evaluation spec v1.0, the Software Factory spec v1.1, and the Build Gate. The docs queue is empty for the first time in weeks.
  • How our testing lanes fit together is now written down. Dave J’s Build Gate proves a candidate is worth evaluating; Dave W’s evaluation plan proves the accepted stories at the UI. Neither re-grades the other.
  • Our AIs are getting their own forum accounts. Each of us will have an agent that reads and replies here on our behalf, so a PR review or a question does not wait for a human to notice it.

What We Covered

Freezing a candidate: A freeze pins the exact commit, spec version, evaluation kit, and judge that a formal run will grade, so the verdict is about one fixed thing and anyone can reproduce it. The last two weeks were a fix-then-retest loop with no fixed target. Today we drew the line: a short list of fixes goes in before the freeze, everything else moves to candidate two, and rows those later fixes affect are recorded as Blocked rather than holding the run. The overnight check that used to put a full day on the critical path becomes a confirming row with a provisional verdict the next morning.

The docs queue: Every spec, plan, and template we accept lives in a docs repo with an approval gate that needs both owners on governance changes. Seven PRs had been waiting on review, and one gate quirk kept blocking merges after approval. We worked through all of them live, including moving the Evaluation Protocol into its own folder and accepting the Model Evaluation spec, which now says a model is recommended for a role only after every app it would serve has passed its own evaluation kit with that model.

Two testing lanes, one artifact: Dave J asked twice last week how his build-side testing and Dave W’s evaluation-side testing should merge. The answer is they do not merge. They stay separate and meet at the Build Gate record, which is a required input to the freeze. Anything Dave J wants proven at the UI becomes an evaluation row; any code defect the evaluation finds goes back through his gate as a reproduction.

Desktop is its own thing: Install, update, and uninstall branch by operating system, so a Docker pass cannot stand in for the desktop builds. That becomes a build item when app lifecycle work resumes.

Agents on the forum: Each of us gets a bot account here. Each agent writes only to its owner’s workspace, can open documentation PRs but never merge them, and answers only its own owner’s mentions. They start in a private staff area until the loop guards are proven, then move to the public categories.

What’s Next

Dave J freezes tonight and runs the Build Gate on that revision; Dave W starts the formal Resume Builder run on it. Dave J’s Software Factory documentation lands in the docs repo this week, then the two-pipeline dev environment so bug fixes and new features stop sharing a branch.

Watch the full recording: