A deployment says Ready. Before moving on, I still want to know: which project, which environment, and when was it checked?
If you maintain several products, those details matter more than another green badge. This is a practical checklist you can use in the provider dashboards, with bookmarks, or in a project panel.
About the examples: I make MakerNotch. The screenshots and videos below use fictional projects, Orbit and Bloom, with sample data—not customer accounts or real revenue.
See the project switch
▶ Watch the project-switching demo
Orbit and Bloom have separate saved connections. Switching projects changes the services you check inside the app; it does not switch your browser's signed-in account.
The checklist at a glance
| Before trusting… | Check… |
|---|---|
| A project label | Repository, team and deployment project |
| A green deployment | Commit or branch and Preview vs Production |
| A revenue total | Account, product, period and currency |
| A reassuring status | Last refresh and connection errors |
| A link to a provider | The account signed in to your browser |
1. Start with the right resource
Write down the repository and deployment project belonging to each product. A friendly name such as Orbit does not restrict what an API token can access.
For Orbit, check the GitHub repository and Vercel team/project. Repeat for Bloom. If both panels show identical data, check those identifiers before replacing credentials.
Keep tokens out of that checklist. Store secrets in the appropriate credential store; the note only needs to identify the resource you intend to read.
2. A passing build is not a production release
Sample data. Notice that both Preview and Production deployments can say Ready.
A passing workflow and a successful deployment answer different questions. Check these in order:
- Commit or branch: is this the change you meant to ship?
- Environment: did it reach Production, or only Preview?
- Behaviour: open the deployed page and try the thing you changed.
▶ Watch the deployment walkthrough
A panel can point you towards the check. It cannot verify the behaviour of your release for you.
3. Give every revenue number a scope
Fictional Bloom project. All amounts shown are demo data.
Before comparing revenue, identify the account, product, period and currency.
For example, MakerNotch's Polar connection accepts an optional product UUID. Leave it empty and the metrics cover the organisation. If that organisation sells several products, calling the total “Bloom revenue” would be misleading.
▶ Watch the revenue walkthrough
Use the provider's reporting tools for reconciliation. Two panels labelled “revenue” are not automatically comparable.
4. Check when the data was refreshed
After switching projects, look at the last refresh and any connection errors. Stale data can still look reassuring.
In MakerNotch, optional automatic refresh follows the selected project. It does not keep monitoring every product while your Mac sleeps. For continuous uptime checks, you need a monitoring service that runs independently of your computer.
5. Use browser profiles for the follow-up
Separate browser profiles remain useful for reviews, deployment settings and billing. A project panel helps you decide which dashboard needs your attention.
Saved connections let MakerNotch read a different project's status without changing your browser session. When you open the original provider, its website still uses the account signed in there. A private repository or deployment may require switching accounts.
A routine you can keep
Select the project → verify the resource and environment → check freshness → investigate anything unexpected.
If you only do this once a day, bookmarks may already be enough. If you want to see the setup used here, the full multiple-projects guide includes the video, connection details and limitations.
Which detail trips you up most when switching products: accounts, environments, or stale data?
Top comments (0)