# RelayCheck PRFAQ
Status: In review
Owner: Maya Chen, fictional product lead
Last updated: 2026-07-19
Decision needed by: 2026-08-07
Evidence reviewed: 14 fictional interviews, nine fictional webhook incidents,
and a six-team fictional prototype cohort
## Future press release
### RelayCheck catches breaking webhook changes before customers do
SaaS platform teams can compare proposed event changes with the contracts their
customers rely on and fix breaking changes before deployment.
**San Francisco, October 15, 2027**: RelayCheck today announced a contract
review service for software teams that publish webhooks. RelayCheck examines a
proposed event-schema change in continuous integration, identifies customer
fields that would break, and returns a report linked to the exact code change.
### Customer problem
SaaS teams often learn that a webhook changed only after a customer's billing,
fulfillment, or reporting process fails. In nine fictional incidents reviewed
for this example, teams had a schema description or release checklist, but the
description had drifted from production events. Engineers then compared logs,
support tickets, and code by hand while customers waited for a fix.
### Product and customer outcome
RelayCheck gives the team one review before deployment. It compares the proposed
JSON event shape with versioned customer contracts, explains which consumers
could be affected, and links each warning to the changed field. Teams can fix a
breaking change, publish a new event version, or record why the change is safe.
### How it works
A team installs the RelayCheck GitHub App or runs the command-line client in its
existing CI job. The team uploads schemas or sanitized example payloads for the
events it wants to protect. On each pull request, RelayCheck reports removed
fields, incompatible type changes, and newly required values. If RelayCheck
cannot infer a safe result, it asks for review instead of blocking deployment.
### Fictional customer quote
> "RelayCheck showed that our small rename would break two customer billing
> jobs. We versioned the event before release instead of explaining an outage."
>
> Priya N., fictional platform engineering manager at Northstar Billing
### Availability and getting started
RelayCheck launches for GitHub-hosted repositories that publish JSON webhooks.
Plans start at a fictional price of $49 per protected service each month. A team
can connect one repository, import one event schema, and run a pull-request
check without routing production webhook traffic through RelayCheck.
## Customer FAQ
### Who is this for?
RelayCheck is for SaaS platform teams whose customers or partners consume JSON
webhooks. It is most useful when several external systems depend on event fields
and a breaking change would cause customer work or support incidents.
### What problem does it solve?
It finds incompatible webhook changes before deployment. It does not replace
runtime monitoring or guarantee that every customer integration is correct.
### How does it work?
RelayCheck stores a versioned contract for each protected event. During CI, it
compares the proposed contract with the current one and comments on the pull
request with the affected fields and consumers. The team can then make the
change compatible, create a new event version, or record a reviewed exception.
### Why would a customer change from the current option?
Teams can keep manual checklists and contract tests. RelayCheck is intended for
teams whose checklists drift and whose tests do not cover external consumers.
Adoption depends on whether its report is more accurate and faster than the
team's current review, which the pilot must prove.
### What does it cost?
The proposed fictional launch price is $49 per protected service each month,
including 1,000 pull-request checks. The pilot tests whether service count is a
clear pricing unit before the price is final.
### How are privacy, security, and reliability handled?
RelayCheck does not need production webhook traffic. Teams can provide schemas
or sanitized examples. The launch design encrypts stored contracts, limits
repository access to selected repositories, records contract changes, and lets
an administrator delete the stored data. These claims require a security review
and failure test before launch.
### What happens when it does not work?
An unavailable or uncertain check reports that it could not reach a decision.
The team can use its existing review and CI process. RelayCheck does not block a
deployment merely because its service is unavailable.
## Internal FAQ
### What evidence shows this problem is worth solving now?
Fourteen fictional interviews covered SaaS teams with 3 to 40 public webhook
events. Nine teams described at least one breaking-change incident in the prior
year. Six provided sanitized schemas for a prototype, and five asked to run it
on a live repository. The sample came from the founders' network, so it does not
yet show demand outside small and midsize SaaS companies.
### Which assumptions could make the idea fail?
The largest assumption is that teams keep contracts current enough for a diff
to help. The second is that RelayCheck can keep false warnings low across real
JSON payloads. The pilot will measure weekly contract updates, reviewed checks,
false warnings, and changes made because of a report.
### What alternatives did we consider?
Teams can use consumer-driven contract tests, hand-maintained schemas, release
checklists, runtime monitoring, or a managed webhook gateway. Contract tests are
strong when every consumer participates. A gateway sees real traffic but adds a
runtime dependency. RelayCheck tests whether a CI-only product can help teams
that cannot require every external customer to run a contract suite.
### What is the smallest useful launch scope?
The launch supports JSON webhook contracts, GitHub pull requests, a command-line
fallback, field removal, incompatible type changes, newly required values, and
reviewed exceptions. It excludes XML, event delivery, payload transformation,
runtime proxying, GitLab, and automatic customer notifications.
### What is hardest to build or operate?
Flexible JSON payloads can make an optional field look required or hide a type
change behind inconsistent examples. The team must define a conservative
comparison model and prove it against the six pilot schema sets. Repository
permissions and data deletion also need tests before the product handles a
customer repository.
### What must be true for the business to support it?
At the proposed price, a protected service must cost less than a fictional $8
per month to operate and support at launch. At least 8 of the first 15 pilot
teams must run checks weekly, and at least 4 must accept the proposed paid plan.
The price, cost ceiling, and conversion threshold are hypotheses.
### How will we measure the customer outcome?
The primary pilot outcome is the share of reviewed pull requests where a team
changes or versions a webhook after a valid RelayCheck finding. The target is at
least 10 such decisions across 15 teams in six weeks. The counter-metric is a
false-warning rate below 5% of reviewed findings. The team will also record
check failures and median review time.
### What could harm customers or the company?
RelayCheck could expose repository metadata, retain sensitive example fields,
or create false confidence when a consumer dependency is missing. The security
owner must approve the permission and deletion model. Product copy and reports
must state that a clean result covers only the contracts supplied to RelayCheck.
### What would make us stop, revise, or delay?
Park the idea if fewer than 8 of 15 pilot teams run it weekly. Revise the schema
model if more than 5% of reviewed findings are false warnings. Delay launch if
the security review cannot confirm repository isolation and complete deletion.
### What remains unanswered?
- Product owner by 2026-07-31: Is protected service count a clear pricing unit?
- Engineering owner by 2026-07-28: Can the comparison model handle the six
pilot schema sets with fewer than 5% false warnings?
- Security owner by 2026-08-04: What repository metadata must be stored?
## Decision
Decision: Proceed to a PRD if the three open questions meet their conditions.
Decision owner: Fictional product director
Reason: The interviews and prototype show a repeated problem, but pricing,
comparison accuracy, and data handling still need bounded proof.
Conditions: Meet the pilot-use threshold, false-warning limit, and security
review before accepting product requirements.
## Evidence and appendix
- Customer evidence: Fictional interview summary, 14 participants
- Incident evidence: Fictional incident review, nine events
- Prototype evidence: Fictional six-schema comparison report
- Financial model: Fictional pilot unit-cost worksheet
- Related decisions: None yet
