Relay
Turn customer demand into approved acquisition work, and learn from what actually happens.
Relay, by Playbook Media LLC, is building a code-native growth execution product for independent software founders. It connects search and website evidence to one practical improvement: choose a relevant opportunity, prepare a narrow change in the founder's repository, obtain exact approval, verify it live, and track later acquisition observations without claiming unsupported traffic or revenue lift.
Today: Relay has a substantial open-source SEO, GitHub publishing and measurement foundation. First proof: an existing-page opportunity → founder-approved GitHub PR → independently verified production change. Company ambition: a recurring customer-acquisition execution business that grows in value with founder-led software companies. Release assurance remains a complementary paid hypothesis; broad Sync, Product Reality Engine and Relay-owned Launch are not the default build direction.
Use Relay · North-star vision · Company thesis · Active growth milestones · RFC implementation specifications
Relay is an independent, MIT-licensed derivative of OpenSEO; it retains upstream attribution, core research capabilities and reviewed upstream-sync. Some internal package and plugin names still say OpenSEO.
Who Relay is for
A solo software founder can have a useful product and a functioning website but still struggle to get the right people to discover it. Keyword software supplies research. Search Console supplies partial evidence about what Google displayed. A coding assistant edits files. Analytics describes sessions and events. The founder still has to decide what is worth doing, explain why, make the change, ship it and remember whether it helped.
Relay's proposed job is to complete that loop with the founder's approval, using the website, repository and analytics accounts they already control.
The first target is a founder-led SaaS or developer-tool business with a GitHub-managed acquisition website, especially Next.js. An early site with little search data receives honest diagnostics and limited market research. A site with real Search Console history can receive query/page evidence, narrow recommendations and relevant follow-up. A founder with important existing traffic may place greater value on Protect's regression checks. None of those scenarios implies that an independent founder has a dedicated SEO employee or product-operations department.
The first founder workflow
- Connect the website and establish context. Set the production origin, repository, intended customer, important page and desired conversion. Connect Search Console and optionally GA4 when authorized. If data is sparse, Relay must say so.
- Review a specific opportunity. Understand which query, page or technical issue was observed, when it was measured, how well it matches the product's buyer, the cost of further research and why the proposal is credible.
- Prepare one bounded change. For supported files, inspect the exact source and proposed diff. If an edit relies on unverified product claims, an unsupported route or ambiguous source, stop and create a reviewable finding rather than guessing.
- Approve the PR, keep deployment control. The founder authorizes the exact write. Relay creates the GitHub proposal; the repository's ordinary checks, review, merge and deployment rules continue to apply.
- Verify and observe. Check the live destination independently when supported. Later, collect eligible Search Console/GA4 observations with enough data. Show technical completion separately from traffic, trials or revenue movement, and label inconclusive results honestly.
This integrated experience is the M13 target, not a claim that all five steps are already automated today. The repository already contains many of the separate components. The product work is connecting them safely and proving the real site-to-code-to-production journey.
A concrete example of good judgment
An existing landing page appears for a buyer-intent search query but has an outdated description. A good Relay recommendation explains the observed query and page, describes the likely intent mismatch, checks the source and proposes a literal replacement only if the code mapping is supported. It does not conclude that changing a description guarantees a different search snippet or additional customers.
A completed technical task means the founder approved the exact change, deployed it through their own process, and the live page reflects the intended supported postcondition. A later Search Console change is an observation that may have other causes. If nothing is safe to change, recommending no action is a legitimate result.
The bigger business we're building toward
Relay's entry product is a code-native SEO and website growth engineer. The business ambition is larger: recurring customer-acquisition execution for software companies as they grow from independent founders into more established founder-led businesses. Our explicit aspiration is to build a company that could support $100M+ ARR. That number is an ambition and useful constraint on strategy, not a customer forecast, proven market opportunity or current run rate.
A founder shouldn't have to open five dashboards, ask a coding assistant to interpret the data, prepare a PR, remember to check the deployment, and months later wonder whether the change produced useful customers. Relay should make that one ongoing, reviewable program. A customer who needs the service every week, trusts its execution and can define meaningful qualified outcomes has a different reason to subscribe than somebody comparing keyword research plans.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
