Example project · A commercial product built from a plan

dig.vin: a commercial product built from a plan with ProPR.

A paid product for used-car buyers, built from a written plan broken into epics. 185 pull requests merged between 17 July and 11 September 2026, 175 of them written by agents, and 124 of them in the first two weeks.

Overview

Project type
A commercial product built from a plan
Where it started
New product; first pull request merged on 17 July 2026
Live product
dig.vin
Code
Private repository

What it is

dig.vin is AI vehicle research for used-car buyers. In its own words: "Research the car behind the ad before you buy it." A buyer enters the car's VIN, the 17-character vehicle identification number, and dig.vin researches the car and produces a report. See it at dig.vin.

The dig.vin home page: the headline See the car's hidden history before you buy, a line on what the AI searches, and a Check the car you're considering box with a 17-character VIN field and a Check a VIN button.
The live home page at dig.vin, captured on 11 November 2026.

Where it started

dig.vin began as a written description of the whole product, broken into epics: the research engine, the reports buyers read, an admin area, billing and the emails the service sends. The first pull request merged on 17 July 2026, and 124 had merged two weeks later.

The plan is what separates this project from Claude Cope, which grew ticket by ticket, and mcptest.io, which grew request by request. dig.vin was designed first and then built, one epic at a time.

How the work ran through ProPR

  1. The plan became epics and issues.An epic is one feature's worth of work, delivered as several pull requests, and an issue is one piece of it. ProPR takes the plan, proposes the issues, and you approve the breakdown before anything is built. 84 of the merged pull requests belong to numbered epics. How planning works.
  2. Agents turned the issues into pull requests.An agent took the issue, worked on its own branch, and sent back a pull request for a person to read. 175 of the 185 merged pull requests were written this way. GPT-5.6 Sol wrote 79, GPT-5.5 wrote 77 and GPT-6 Astra wrote 18.
  3. Each epic landed as a reviewed set.Pull requests for one epic collect on that epic's branch, each reviewed before it merges, and billing and email went through the same review as the research engine. How an epic lands.

The numbers, as of 11 November 2026.

185merged pull requests, 17 July to 11 September 2026
175written by agents through ProPR
124merged in the first two weeks
84pull requests in numbered epics

Agents that wrote the pull requests: GPT-5.6 Sol (79 pull requests), GPT-5.5 (77), GPT-6 Astra (18). Counts come from the private repository on GitHub.

What the pull requests built

The repository is private, so the pull requests stay inside it. The work covered the whole product:

  • The research engineThe part that digs up a car's history from the vehicle identification number.
  • The buyer-facing reportsWhat a buyer reads after a check.
  • An admin areaThe screens the team uses to run the service.
  • BillingPaying for a report.
  • Transactional emailThe messages a buyer gets, such as a report being ready.

For pull requests you can open and read, see Claude Cope and mcptest.io, whose repositories are public.

What this shows for your own project

For a product you mean to sell, write the plan down first. ProPR turns it into epics and issues, you approve the breakdown, and the product arrives as reviewed pull requests, one epic at a time, with the parts that handle money and customer email reviewed like everything else.

When the plan changes, you change the plan and the next epics follow it. The repository records what was built, in what order and by which agent, so the 185 pull requests double as the product's build log.