ProductBuilder
Drop an AI project manager into your Slack — like the single point of contact you’d get from an external dev agency. They hear the request, clarify the scope, brief the coding agent, spin up a live preview of the result, and bring feedback back. All without your non-technical teammates ever opening GitHub, and without pulling a developer in for every small change.
Talk in Slack. Review a live preview. A developer still handles the merge.
A short walkthrough of a non-tech teammate adding a light/dark theme switch to a directory site — from the Slack request to a working preview.
Imagine hiring an external dev agency as an extended workbench for your internal software team. That agency would put one project manager on your account — the single contact your product people speak to. You’d invite that PM into your own Slack, and they would take care of everything else on your behalf.
ProductBuilder is that PM — plus the full machinery behind them. Non-technical teammates just describe what they want in Slack. The PM scopes the work, briefs a coding agent that actually writes the code, deploys a live preview of the result, relays feedback until everyone’s happy, and hands the PR back ready for developer review.
The low-level details — GitHub issues, pull requests, OpenCode runs, preview systems — stay fully encapsulated. Your product team never leaves Slack. Your developers get well-scoped PRs instead of back-and-forth over specifications. The system’s job ends at producing a good PR; the final review and merge stay with a human developer, where they belong.
The whole flow — request, code, review — ships together. Each pillar carries a specific part of the loop.
Your non-technical teammates mention @ProductBuilder in Slack. The PM listens, asks clarifying questions when the request is vague, and decides what to do — open an issue, delegate work, answer a question, close something finished.
It tracks each conversation across its whole lifecycle, so follow-ups land on the right workstream instead of starting from scratch.
Once the PM has scoped the request, it hands the work to the coding agent the setup ships with. The agent reads the issue, writes the code, and opens a pull request against your target repository.
Simple product changes never need to land on a developer’s plate — the loop from request to PR happens on its own, with the PM narrating progress back in Slack.
Powered by OpenCode, invoked via a CI workflow the setup installs alongside the orchestrator.
Every pull request that the agent (or a developer) opens gets a live preview at a stable URL, deployed automatically behind Traefik and refreshed on each commit.
Non-technical reviewers click one link, try the change for real, and give feedback in the same Slack thread. The preview tears itself down when the PR closes.
One request, traced end-to-end.
A product teammate writes @ProductBuilder add dark mode support. The PM asks any missing questions — whole app or just one area? OS preference or manual toggle? — and opens a well-scoped GitHub issue with the clarified context baked in.
The PM delegates the work. The coding agent reads the issue, writes the code, and opens a pull request. The teammate never leaves Slack — the PM narrates progress as it happens.
The PR triggers an automatic deploy behind Traefik. Within minutes the PM drops the preview URL into the Slack thread — “Try it here: pr-52-preview.example.com.” Every new commit refreshes the same URL.
The teammate gives feedback in Slack. The PM relays changes to the coding agent, which pushes updates; the preview refreshes each time. When the teammate’s happy, the PR is marked ready — a developer still does the final review and merge.
A single Go orchestrator talks to Slack, GitHub, and Claude — and runs previews itself.
ProductBuilder is open source. Deploy it once on a single EC2, point it at your Slack workspace and your target repos, and let the PM-style agent take it from there.