If you want to start a pilot without creating extra work for your team, begin with a read-only GitHub App install, then map the right teams and repos, and finally verify the first synced data. That sequence keeps setup simple and gives you scoped KPIs you can trust. It is a practical way to apply engineering intelligence for GitHub PR delivery while keeping the experience coaching-focused, not surveillance-oriented.
What a good pilot setup looks like
A pilot should answer one practical question: can we connect GitHub, map the right scope, and get usable delivery metrics fast enough to inform a manager’s weekly rhythm? For most teams, the setup is straightforward because the app is read-only and syncs daily.
- Install the GitHub App with the permissions required for read-only access to GitHub PR metadata.
- Connect the account through the OAuth flow.
- Map teams and repos so the pilot covers only the scope you care about.
- Check the first dashboard view for team KPIs and trend charts.
If you want the full setup path, start with /docs/setup and /docs/how-it-works.
Connect GitHub first, then worry about the rest
The fastest way to slow a pilot down is to overthink structure before GitHub is connected. The app install and OAuth connection are the foundation. Once that is in place, you can decide which teams and repos belong in the pilot.
Keep the initial connection narrow
Start with the repositories and teams that best represent the delivery flow you want to understand. A smaller pilot is easier to validate and easier to explain to stakeholders.
Use read-only access to reduce review overhead
Because the app is read-only, managers usually spend less time explaining data access concerns. That helps move the pilot from approval to actual measurement without adding pressure on contributors.
For more detail on what the platform needs from GitHub, see /docs/how-it-works and /docs/limitations.
Map teams and repos before you judge the numbers
Pilot results are only useful when the scope is clear. If teams and repos are not mapped well, the metrics may look noisy even when the data is correct.
Decide the pilot boundary
Choose whether you are measuring one team, a set of related teams, or a small slice of repositories. The goal is not to capture everything at once. The goal is to create a clean baseline.
Check that the mapping matches how the team works
Review ownership, shared repos, and any edge cases before the pilot starts. If a repo contributes to more than one team, document that decision so the dashboard stays understandable.
Use /docs/teams-and-repos to confirm the mapping model, and /docs/metrics to align the pilot with the KPIs you plan to review.
What to verify after the first sync
Once the first daily sync completes, do a quick check before you treat the pilot as live. You are looking for completeness, scope, and obvious mismatches.
- Confirm the expected teams and repos appear in the mapping.
- Open the overview dashboard and check the team KPI cards and trend charts.
- Review the team performance table for obvious outliers or missing rows.
- Drill into one or two charts to make sure the detail view matches expectations.
If the data does not look right, start with the scope and mapping before assuming there is a product issue. The /docs/troubleshooting page and /docs/faq are the best place to narrow down setup issues.
Use the first week to validate the pilot, not to optimize it
The first week should tell you whether the setup is solid enough for repeatable reporting. That means watching for stable scope, understandable trends, and enough signal to support team conversations.
Look for consistency, not perfection
Early data often reflects the shape of your GitHub activity more than the shape of your process. A pilot is successful when the metrics are consistent enough to support decisions and discussions.
Match the pilot to your management cadence
If you run weekly staff meetings, connect the pilot to the questions you already ask: where is work moving slowly, where is review lagging, and which teams need attention. You can pair the dashboard with /docs/weekly-summary if you want a lightweight weekly view.
For examples of how managers use the data after setup, see /docs/dashboard and /docs/team-analytics.
When to expand the pilot
Expand only after the initial scope is clearly mapped and the metrics are being reviewed consistently. A pilot is ready to grow when you can explain the numbers, not just display them.
- The connected teams match the intended pilot scope.
- The dashboard shows stable trend lines over daily syncs.
- The team can interpret the results without needing constant setup review.
- You have identified the next team or repo set to add.
If you want a broader view of the product before expanding, the /docs/product-tour and /docs/chart-milestones pages are helpful references.
FAQ
How long does a pilot setup usually take?
Most of the setup time is spent on GitHub connection and confirming team and repo scope. Once that is done, the first daily sync can populate the dashboard quickly.
Do I need to map every team before I start?
No. Start with one team or a small group of repos that represent the process you want to measure. You can expand the mapping after the pilot is validated.
What should I check if the dashboard looks incomplete?
Start with the team and repo mapping, then confirm the GitHub App connection and sync status. If the issue is still unclear, use /docs/troubleshooting.
Can I run the pilot with read-only access?
Yes. The app is designed for read-only GitHub access, which makes it easier to get approval for a pilot and reduces disruption for contributors.
Where should I go after the pilot is connected?
Review the dashboard, check the weekly summary, and decide whether the current scope is enough for your management cadence. If you are ready to proceed, create your workspace at /app/onboarding.
If you are ready to start, begin the pilot at /app/onboarding and use the docs to confirm setup, scope, and next steps as you go.