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:

23

September 14, 2026 Update

This week’s call was mostly about the BrainDrive Software Factory: the formalized, AI-run process we’re using to build BrainDrive as a small team, with a walk through every stage of the line. Dave J also had a couple of product updates from last week.

Key Highlights

  • Code freezes are now in place, so Dave W, Dave J, and the AI all test the exact same build.
  • The Rust desktop app’s sidecars are coming to life: the workspace came up on Windows with apps loading from their own GitHub locations via the catalog. Windows wraps up first, then Mac.
  • The Software Factory is now running end to end as a working rough draft, and every stage is visible and fixable rather than conceptual.
  • Each run through the factory is getting tighter, and the same process is designed to eventually power “BrainDrive Code” for every owner.

What We Covered

Why a factory at all: Building a superior user-owned alternative to big tech AI means playing a different game. Instead of raising venture capital and hiring a huge team, we’re leveraging AI to keep the core team small and leaning on the open source community, which already exists at scale. The factory is how we make that work legible to AI so it can partner with us at every step.

Freezes and the desktop app: Freezes let us lock a candidate so everyone tests the same thing, with no mystery midnight updates. On the desktop side, apps are moving out of the monolithic install and into a catalog-driven model where BrainDrive discovers and pulls in apps from wherever they live. This is a step toward an open app marketplace where apps like Resume Builder can run in BrainDrive or any system that speaks the same open protocols.

The stages of the Software Factory: Dave W walked through the full line. Select decides what enters the factory via a prioritization workflow and produces a sequencing doc. Specify and Spec use an interview process to define what success looks like as user stories. Evaluation Plan defines how the AI and the team will know the user stories are met, including judge kits for things like interview quality. Ground and Plan gives the AI the project profile, build context, build plan, and running learnings. Build breaks the plan into bounded work specs that are each built and verified before moving on. A standard Build Gate runs before hand-off. Evaluate and Remediate runs the full acceptance criteria against a frozen candidate, preceded by a quick smoke test to catch obvious breakage. Then Qualify and Package seals the evidence, Release ships it, Capture and Learn feeds lessons back into the factory, and Dispose clears the finished work.

Why it matters to developers: Every decision, its reasoning, and its sources are now on record, so when something goes wrong we can trace it back to the context we gave the AI and fix the docs. Keeping context windows tight limits hallucinations, and it lets us use frontier models for planning while cheaper, faster models handle the coding, which stretches the token budget much further.

What’s Next

Finish the Windows desktop cleanup and port to Mac, then freeze builds for both desktop versions. Keep running work through the factory, dialing in each stage for speed and evidence of the dividends it’s returning. Longer term, this foundation is what BrainDrive Code will be built on, letting any owner describe what they want in plain language and have their BrainDrive build it.

Watch the full recording: