Brad Zhang / public archive

Brad Zhang

AI product notes, agent workflow writing, and open-source dossiers for founders and early technical teams.

Paid collaboration / North American AI startups

Bring me the AI workflow that is too important to stay fragile.

I work with early AI teams on agent workflows, developer tools, internal copilots, technical documentation, memory, validation, and product surfaces that need to become reliable enough for real users.

Editorial workbench for AI-native developer tooling collaboration

Engagement formats

Three practical ways to start.

01 / Design partner sprint

Make one AI workflow reliable enough to ship.

Two weeks

Agent tooling, internal copilots, devtool UX, technical docs, memory, evals, workflow automation

A working module, product surface, or documentation workflow with constraints, examples, quality checks, and handoff notes.

02 / Founding engineer trial

Work together before making a full-time or founder-level decision.

Four to six weeks

Early AI teams that need product-minded engineering across ambiguity, UX, implementation, and launch

A concrete product milestone plus enough operating evidence for both sides to evaluate deeper fit.

03 / Developer-facing proof sprint

Turn an invisible technical capability into a public artifact buyers can understand.

One to two weeks

Launch docs, repo positioning, demos, diagrams, founder updates, technical onboarding, OSS packaging

A founder-ready narrative layer: case study, diagrams, README structure, examples, and a stronger public technical surface.

Commercial proof ladder

The paid path starts where public proof is already strongest.

The site is intentionally not monetized like a content farm. The first revenue path is high-trust work around AI workflows, developer-facing product surfaces, and technical distribution.

High-trust lane 01

Founding engineer fit

Early AI teams that need product-minded engineering around agent workflows or developer tools.

Open-source traction, shipped product surfaces, X field notes, and a founder-readable site.

A concrete trial module with a repo, demo, docs, or workflow to inspect.

High-trust lane 02

Design partner sprint

Teams with one fragile AI workflow that should become reliable, inspectable, and reusable.

The AI Devtool Sprint offer, proof clusters, and case-study style artifacts.

A two-week paid sprint around one artifact and one handoff.

High-trust lane 03

Developer-facing proof work

AI infra, devtool, and internal-copilot teams whose product is strong but hard to explain.

fireworks-tech-graph, project dossiers, technical diagrams, and launch narrative systems.

Package the capability into docs, diagrams, examples, and a public proof surface.

Fit signals

This works best when the problem is already painful.

I am a better fit when the team has a concrete workflow bottleneck, a product surface that users need to trust, or a developer-facing capability that needs to become legible outside the founding team.

You are building an AI-native product where workflow reliability matters more than a flashy demo.

You need someone who can cross product framing, implementation, validation, docs, and launch packaging.

Your team is early enough that one strong builder can still change the shape of the product surface.

You want to start with a scoped paid sprint before discussing employment or cofounder-level work.

What to send first

A useful first message is specific.

01

What workflow is currently too fragile, manual, or hard to explain?

02

Who needs to trust or adopt it: developers, operators, customers, investors, or internal teams?

03

What would count as a useful shipped artifact within two weeks?

04

What existing code, docs, diagrams, prompts, or workflows should I inspect first?

Work With Brad Zhang | AI-Native Developer Tooling