Business productBuilt from a plan, February 2026
A messaging-assistant platform, built from a plan in hundreds of small steps.
A conversational assistant delivered through messaging apps, with an admin console, onboarding flows, safety monitoring and analytics. It went from an empty repository to a working product through more than 770 merged pull requests, more than 650 of them written by agents through ProPR.
This project is private. It is described here with its owner's permission, with identifying details left out.
Public record
What it is
A business asked for an assistant its users could talk to inside the messaging apps they already use. Around the assistant sits everything a shipped product needs: an admin console for the people running it, onboarding flows for new users, safety monitoring on the conversations, and analytics on how it is used.
It is still maintained through ProPR in November 2026. New work arrives the same way the first work did, as pull requests the owner reads and merges.
Where it started
The repository was empty and the plan was written. It described the product in plain language and was split into epics: features too big for one pull request, each delivered as several smaller ones that are reviewed on their own.
The first pull request, on day one, set up the infrastructure and the tests, so every later change ran against checks that already existed.
How the work ran through ProPR
The plan was broken into epics, the epics into issues, and an agent took each issue into its own isolated workspace and came back with a pull request that showed the owner exactly what was different.
More than 660 pull requests merged in the first seven weeks, February and March 2026. That pace was possible because the pieces were small: a pull request that changes one thing takes minutes to read, so a single reviewer kept up with hundreds of them.
Most of the work was written by Claude Opus. Later work added GPT-5.4. Switching the model behind an issue changes nothing about the process: the request, the branch, the pull request and the review look the same whichever agent did the writing.
Nothing merged without the owner's say, and a comment on a pull request sent it back for changes. GitHub keeps every merged pull request in the history with a Revert button, so a wrong change can be taken back out without reopening the hundreds around it, though a revert sometimes needs a follow-up when later work built on the change.
The numbers, as of 11 November 2026.
Rounded counts from the private repository, shared with the owner's permission.
Example work
The pull request titles stay private. The kinds of work are the kinds every product needs:
- Infrastructure and tests first. Day one set up how the product builds, runs and checks itself, so later pull requests ran against the test suite.
- The assistant. The conversation flows users see inside their messaging app, delivered one behaviour at a time.
- The admin console. The screens the business uses to run the product, planned screen by screen as issues.
- Onboarding, safety monitoring, analytics. Whole areas of the product, planned as epics and landed as runs of small pull requests.
What this shows for a product of your own
Start with a plan in plain language, let ProPR split it into epics and issues, and let agents turn the issues into pull requests that you read, comment on and merge. The product grows in steps you can see, and the plan tells you what comes next.
The habit that made the pace possible is the one to copy: keep each pull request to one change, because a change that small is quick to read and quick to take back out.
How planning works, and for your own server, self-host ProPR.
For an admin console or internal tool of your own, the dashboard walkthrough plans one screen per issue, the way this product's console was built.