The repository and flypython.com should form one user journey without becoming duplicate websites.
| Layer | User value | Owns |
|---|---|---|
| GitHub repository | Inspect, run, verify, reuse, and contribute | Source guides, playbooks, examples, templates, catalog records, tests, and manifests |
| flypython.com | Discover the right path and continue learning | Presentation, search, navigation, newsletter, progress, and live offers |
The website consumes a pinned repository commit. A website-only editorial copy must not become a second source of truth.
- A visitor lands on a README, guide, example, or search result.
- The visitor completes a small useful outcome in the repository.
- One contextual call to action offers the next step on flypython.com.
- The website may invite an email subscription after delivering useful content, not before.
- A paid offer may appear only when its scope, price, delivery, support, and refund behavior are live and verifiable.
Good calls to action continue the current task: a guided learning path after a guide, related tools after an example, or reviewed updates after Project Radar. Avoid generic banners, repeated marketing copy, and links to placeholder pages.
The dedicated /from-github landing route is now in production. Repository
calls to action may link to that route when attribution matters, while generic
“continue learning” links may still use the site root. Re-verify the custom
domain after each website release. Measure, at minimum:
- repository link clicks by source document;
- landing-page engagement with a learning path;
- newsletter opt-ins attributed to the repository;
- requests for a clearly defined service or product;
- confirmed payments and completed delivery, kept separate from registrations or pricing-page views.
Do not treat stars, traffic, email signups, a checkout route, or a deploy log as paid-demand evidence. Review the funnel monthly and remove calls to action that do not help visitors take a useful next step.