On this page
What you're really selling hereThe proof point, in plain termsHow to pitch itObjection handlingCompetitive angleKeep it honestOne-liner for a deckFor Sales
What you're really selling here
Nothing in this PR is a line item on a contract. But the pipeline it lives in is a strong proof point about engineering rigor — useful when a prospect (a larger clinic group, a partner, an investor) asks "how do you keep quality high while moving fast?" This page gives you that talk track and keeps you honest about what's real.
The proof point, in plain terms
"Before any change reaches production, our system automatically stands up a complete, data-seeded copy of Dentolize for that exact change, runs AI quality checks against it, and writes a plain-language walkthrough of what changed. This particular improvement lets our team watch that walkthrough being written and know precisely when it's ready — so nothing ships on a false 'it's done' signal."
How to pitch it
- Lead with the outcome, not the plumbing. Prospects care that changes are
reviewed thoroughly and predictably — not about GitHub Actions runners.
- Anchor on trust. The whole point of this change is replacing a misleading
"done" with a real one. That maps directly to "we don't mark things complete until they actually are."
- Show, don't tell. The Feature Tour has real screenshots
of a per-change preview environment. That's the tangible artifact.
Objection handling
| Objection | Honest response |
|---|---|
| "Is this an AI writing our clinical docs?" | No. The AI writes an internal walkthrough of a code change for a throwaway preview environment. It never touches patient data or production docs. |
| "Does AI docs mean you cut corners on human review?" | The opposite — it's added on top of human review to make changes easier to understand. Humans still review and merge. |
| "This sounds slow — an hour per change?" | Only the on-demand docs refresh can take up to an hour, and only when it must build a preview environment from scratch first. It runs in the background of the team's day; it doesn't gate the product. |
| "How do you avoid one long job blocking everything?" | We added a second build slot precisely so long jobs (docs, QA) never block the quick per-change deploys. (See the honesty note below.) |
Competitive angle
Most teams ship with a static staging environment and hand-written release notes that lag the code. The differentiator to draw: per-change preview environments + auto-generated, always-fresh walkthroughs. This PR is the detail that shows the team keeps sharpening that machine rather than letting it rot.
Keep it honest
- Don't promise this to customers as a feature — it's internal tooling.
- Don't claim speed gains — there are none; the gain is **visibility and a
trustworthy completion signal**.
- The "second runner slot" is real per the PR, but it's an infrastructure change
outside the code you can point to. Say "we scaled our build capacity," not "here's the code that proves it." See For Quality.
One-liner for a deck
"Every code change gets its own live copy of the app and an AI-written walkthrough — and our team watches it build in real time."