The dashboard, at /app, is where you see every product you operate and what needs you. It reads each product’s state from its Operations Instance. It holds no GitHub credential of its own, and it never writes to your repositories except by opening a pull request you asked for.
Pages
| Page | Shows |
|---|---|
| Workspaces | Your workspaces. With one, you go straight to it. A workspace can span several GitHub organizations. |
| Overview | Every product in the workspace, what it is doing, and what needs you |
| Products | Discovery: every product Startup OS found in your connected organizations, and where you start onboarding |
| A product | One product’s go-to-market at a glance, then its health, mode, activity, and onboarding |
| Scoreboard | The quarter’s bets against their targets, the weekly numbers, each bet week by week, and this week’s choices |
| Motions and tests | Each go-to-market motion by stage, the experiments deciding it, the beliefs, and the monthly ranking |
| Journey and content | How far people get through the product’s milestones, paid experiments, and published stories |
| Reviews | Every weekly, monthly, and quarterly review |
| Decisions | Requests that need a named founder, and their history |
| Configuration | One product’s settings, and where you propose changes. See Your product’s settings. |
Inside a product, the sidebar lists all of its pages, and under the page you are on, that page’s sections. The section you are reading is marked as you scroll.
Connecting an organization
A workspace starts with no organization. There are two buttons because GitHub behaves in two ways:
- Install on a new one installs the Startup OS GitHub App on an organization that does not have it yet, and brings you back.
- Connect an existing organization is for an organization that already has the app. GitHub does not send you back from those, so this asks you to sign in once and pick the installation instead.
Connecting writes nothing to your repositories.
The overview
Products are grouped as Operating, which are already running, and Onboarding, which are everything else. Each row answers five questions.
Status: is it healthy?
| Label | Means |
|---|---|
| Healthy | The product reported recently. |
| Stale | Its last report is older than its cadence allows. The last update’s age is shown. |
| No status yet | The product has not reported. Normal between onboarding and its first run. |
| Status file is unreadable | Its report exists but is invalid. The reason is shown. |
| Startup OS could not check | Startup OS could not reach it. The reason is shown. |
Doing: what did it last do?
| Label | Means |
|---|---|
| Made progress | The last run produced something. |
| Nothing to do | The last run found nothing worth doing. |
| Declined to act | The last run chose not to act, and said why. |
| The run failed | The last run did not finish. |
| Waiting for you to merge | Onboarding is waiting on your pull request. Links to it. |
| No run yet | Nothing has run. |
Needs you: is anything owed?
| Label | Means |
|---|---|
| Nothing owed | No action needed. |
| Worth a look | Something is worth checking, but nothing is blocked. |
| Needs a decision from you | A decision is open. The count of open decisions is shown. |
| Update ready | A platform update is ready to merge. |
The Needs you count at the top of the page counts decisions only.
Operating mode and setup
Operating mode is one of Observe, Prepare, Operate, Paused, or Archived, with a line on what it permits. It is worked out from the product’s permissions, never set directly. See Permissions and operating modes.
Setup says how discovery found the product:
| Label | Means |
|---|---|
| Ready to onboard | No Startup OS configuration yet. |
| Partly set up | Some Startup OS documents, but no manifest. |
| Already running | A manifest is in place. |
| Running, configuration out of date | A manifest is in place, but it is not compatible with the current platform. |
| Startup OS could not tell | The repository was too large to read in full. |
Products and discovery
Opening Products runs discovery. It reads your repositories and writes nothing. A product whose repositories are settled shows Confirmed product repositories. One that Startup OS grouped by repository name shows Inferred, not yet confirmed: when you start onboarding it, you tick the repositories that belong to it and confirm its name. One product per organization is supported, and it can span several repositories.
Start onboarding appears beside a product that has no onboarding run and is not already running. Startup OS creates a private operations repository, or reuses the one you have, and opens a configuration pull request in it. See the Quickstart.
A product’s page
Sections appear in this order, and some only when there is something to show:
- Health: the status above, in more detail.
- Operating mode: the mode and what it permits. Startup OS never changes it.
- Platform: whether a platform update is ready, and the Update button when it is.
- Needs you: open decisions, with a link to them in the Instance.
- Recent activity: what the product has done lately.
- What Startup OS cannot see: evidence sources that are missing, so you know what its judgments are made without.
- Your first assessment and operating plan: once the configuration is merged, the checks the first run needs, each with what to fix, and Run first assessment and plan. It then links to the run on GitHub, and to your assessment and plan when they exist.
- Onboarding: each stage, and a link to review the pull request while one is open. Try again appears when the proposal failed.
- Identity: the product’s id, setup, grouping, and repositories.
The page does not refresh itself. After you merge something, reload it.
Onboarding stages
| Stage | Means |
|---|---|
| Found by discovery | Discovery has seen the product. |
| Organization connected | The app can reach it. |
| Preparing the proposal | Startup OS is building the onboarding pull request. |
| Waiting for you to merge | The pull request is open. Nothing moves until you merge. |
| Understanding the product | Merged. Waiting for the first run’s assessment. |
| Drafting the operating plan | The assessment exists. Waiting for the operating plan. |
| Onboarded | The assessment and operating plan both exist. |
Startup OS checks for the first run’s assessment and operating plan every ten minutes, so these stages move on even when nobody has the page open.
If you close the onboarding pull request without merging, the product returns to Organization connected and is marked Worth a look. Start onboarding again when you are ready.
Platform updates
When the platform releases, it opens an adoption pull request in each product’s Instance. The product’s page shows it under Platform once its checks pass. Update merges it as you, with your own GitHub account, after GitHub confirms it is you. Startup OS never merges an update itself.
Founder requests
From a product, open Read requests and respond. Explicit requests show why now, evidence, options and consequences, recommendation, deadline, estimated attention and capital implications. Unknown estimates are counted separately from known minutes. Unreadable records and expired requests require reassessment instead of a guessed empty queue.
The required signed-in founder can accept an offered option or reject the request with a reason. This prepares a GitHub review; merging the decision creates the lasting response. Accepted and rejected records stay in history. A response tied to experiment or GTM state uses its combined state review in GitHub. The control never spends funds or merges a pull request.
Go-to-market pages
When a product adopts GTM records, its page opens with the go-to-market at a glance: the quarter as weeks, each bet’s primary measure against its target, and how many motions, tests, reviews, and decisions are open. Open scoreboard goes to the detail.
The Scoreboard draws each measure on one track: the tick is the baseline, the bar is the latest reading, and the line is the target. A measure with no reading has no bar, and a target written as a decision rather than a number is shown as words. Under it are the weekly review metrics, one small chart each on its own scale, and each bet’s state in every weekly review. What changed this week lists the latest review’s choices, and What the system is doing about it lists accepted priorities. Open Review requests to see recommendations and consequences before responding.
Motions and tests places each motion in the stage the thesis says it has reached, and draws each experiment against the date its result is reviewed, with today marked. It also lists the thesis’s hypotheses with their evidence and confidence, and the last monthly review’s ranking.
Every chart has the same numbers in a table or a list beside it. A proposed plan has not replaced the approved plan. Accepted priorities can still lack an execution adoption receipt; an adoption receipt is separate from business results. Unknown, unavailable, private and stale observations remain explicit, while measured zero stays zero. Illustrative records carry a synthetic label. Source links open the exact repository revision read by the page.
No GTM adoption, an incomplete source or an older connected App leaves these pages unavailable; your operating status stays on the product’s page. Business records are read on demand. Reload for a fresh snapshot before deciding. Capital and attention distinguish recorded amounts, estimates and unknowns without authorizing a payment.
Review a new test
Use the GTM workflow to distinguish a designed proposal, registered definition and admitted running test. A dashboard response stages a decision proposal; it does not start the experiment. Coupled strategy or experiment acceptance uses the complete review bundle, and action-specific permissions remain separate. A provider receipt or accepted strategy is not measured customer success.