Case study · A marketing site run through ProPR
How this website is built and run with ProPR
propr.dev, the site you are reading, started as a hand-built marketing site in April 2026. Since June 2026 its changes have gone through ProPR: a written request, a pull request with the exact changes, and a person who reads the result and says yes. On the recent epics a second AI model reviews each pull request before that person sees it. The numbers and examples come from the site's own repository history, as of 11 November 2026.
Overview
Six words, explained once
GitHub keeps software in a few simple shapes. These six carry the whole story.
| Repository | The folder of files that make up the site, with every version ever saved. |
|---|---|
| Issue | A written request for a change, kept next to the files. One issue describes one change. |
| Branch | A working copy of the files where a change takes shape without touching the live site. |
| Pull request | The proposal to bring a branch's changes in. It shows every line added or removed and holds the conversation about them. |
| Review | A reader going through the pull request and listing what must change before it lands. |
| Merge | Accepting the pull request. Only then does the change reach the site. |
How one change lands on propr.dev
- Write the request as an issue. Say what the page should do and which files the change may touch. “Compare: tighten hero ledes on competitor pages” is a complete brief from the history, and it became a merged pull request the same evening.
- ProPR opens a pull request. An agent works in its own isolated copy of the site and runs the checks. ProPR pushes the branch and opens the pull request under its own name, so the agent never holds write access to the repository. Each pull request also gets a preview address, so you click through the proposed site before deciding anything.
- Related pull requests gather on an epic branch. Seven “Marketing voice” and pricing pull requests landed on one branch called
epic-marketing; a single merge then carried the whole theme to the live site. Ten epics have landed this way. If a theme turns out wrong, one merge is what you undo. - A second model reviews. On the recent epics Claude Fable 5.1 wrote the pull requests and GPT-6 Astra reviewed every one, posting numbered findings. ProPR applies each fix as a follow-up commit and asks for a fresh review until the score reaches the target, 8 of 10 on this site. That loop is Ultrafix.
- A person validates and merges. The site's owner merged 110 of the 113 merged pull requests by hand; three in June 2026, the first month, were merged by ProPR itself with auto-merge on. Since then, nothing has reached propr.dev before that click.
Work from the history
The issue titles below are quoted as written. Each became a pull request, and the related ones shared an epic branch.
A copy sweep across the site
Five issues on 2 November, each titled “Voice and messaging pass on …” and scoped to one group of pages, rewrote the playbooks, the commercial and trust pages, the agent pages and the feature pages in parallel. A week later seven more, from “Marketing voice: homepage and workflow pages” to “Marketing voice: comparison pages”, landed together on epic-marketing. Splitting a site-wide rewrite into page groups is what let twelve pull requests merge without stepping on each other.
SEO and image work
“SEO: titles and meta descriptions tuned to search data”, “SEO: structured data, per-section social cards, sitemap lastmod” and “Performance: WebP images, intrinsic dimensions, lazy loading” shipped as one epic. The image task converted the site's pictures to WebP and added a check that now fails the build when an image lacks dimensions or alt text, so the rule outlives the task.
The guides section
“Guides: six search-intent guides and a hub” created the Guides section, with one data file that feeds every guide's title, description and structured data. A follow-up, “Guides: inbound links from existing pages and llms.txt”, wired the new pages into the rest of the site.
The comparison pages
Two issues fact-checked the competitor pages in halves, “Compare: fact-check competitor pages A–F with verified dates” and “… G–Z and category pages”, each claim re-verified on the web and dated on the page. “Compare: restructure the index, merge app-builder pages, clean up the template” then reorganised the section. 32 comparison pages and a hub carry the result.
Security headers
“Hygiene: security headers, asset caching, video weight” added a strict transport header, frame protection and a Content-Security-Policy, which tells the browser exactly which origins may run scripts on the site. The same pull request added a check that fails the build when any page uses an origin the policy does not allow.
The numbers, as of 11 November 2026
The first ProPR pull request merged on 6 June 2026, six weeks after the site's first commit. Every count comes from the repository's merged pull request list, its closed issues and the build output.
The checks every change passes
One command, npm run verify, runs on every pull request and again before each deploy. It covers:
- the full site build;
- every internal link and asset reference (12,397 of them resolved on the last run);
- 33 regression tests, including the page-date logic behind the sitemap;
- every page title under 60 characters and every description between 110 and 160, with no duplicates;
- every image with dimensions, alt text and a WebP source;
- the Content-Security-Policy against every origin the built pages use;
- the cache rules, so versioned assets are the only ones served as immutable.
A pull request that fails any of these shows a red check, and the review loop waits for green before it continues.
What went wrong, and how review caught it
“Marketing voice: homepage and workflow pages” asked for shorter, bolder copy. The agent delivered it, and in three places the boldness outran the facts. The Automations page now said a run past the subscription threshold “waits for the window to reset”, when some runs are skipped. A later version promised that “a run never burns the last of your allowance”. The page for engineering leads said every agent change gets “a plan, a pull request, a review and a full history, by default”, when planning and review are features you turn on.
The reviewing model, GPT-6 Astra, scored the first version 6 of 10 and listed each overpromise as a merge blocker, with the sentence, the file and the reader it would mislead. ProPR applied a fix commit after each round. The fourth review found no blockers and scored the pull request 9 of 10, 22 minutes after it opened. The owner merged the epic later that day. The review step earned its place on one pull request. It has run on 65 of the 113 merged so far, and on every one in the recent epics.
Three lessons for your own project
- Write small requests. The issue titles above are the entire brief in most cases: what to change, which pages, and what is out of scope. Small requests give you pull requests you can read in a few minutes, and a scope line keeps parallel work from colliding.
- Put a second reader between the agent and the merge. A model that did not write the change reads it with fresh eyes and cites the line it objects to. You read only what survived, and you still hold the merge button.
- Turn the rules you care about into checks. Title lengths, alt text, allowed origins and dead links all started here as review comments and became lines in
npm run verify, where they run on every pull request and never need remembering.