StudioDash is currently in development and preparing for a controlled private beta. The BarkinMad Studios website now includes a documented StudioDash product section with overview, feature, integration, dashboard, analytics, reporting, sync, security, FAQ, guide, release-note, private-beta, and screenshot pages.

Private beta access, App Store information, wider public availability, and release timing will be published when BarkinMad Studios is ready to announce them. Until then, public documentation should describe the product direction conservatively and avoid presenting roadmap items as released features.

The initial public StudioDash documentation introduces the product as a native Mac and iPad dashboard for indie app and game developers. It explains how StudioDash brings app, revenue, website, search, provider health, sync, and trend signals into one operating workspace.

The documentation also establishes the public terminology used across the site: private beta, provider health, selected-period summaries, placeholder coverage, roadmap automation, and the distinction between demo, placeholder, and live data.

• Overview and Features explain the product direction and core operating model.
• Integrations, App Store Analytics, Revenue Analytics, and Website & SEO Analytics explain the provider-backed surfaces.
• Reporting, Automation & Sync, and Security & Privacy explain how to read provider data responsibly.
• FAQ, Guide, Release Notes, Private Beta, and Screenshots provide supporting product information.

Current public documentation covers App Store Connect, AdMob, AdSense, Cloudflare, Google Search Console, Google Ads placeholder coverage, and GitHub placeholder coverage. It intentionally separates implemented coverage from planned or placeholder areas.

Provider-specific details should remain conservative while StudioDash is in development. If an integration requires setup, has no data for a selected period, is not configured, or remains planned, the public copy should say so clearly.

Future release notes should focus on public product changes, availability milestones, newly released integrations, visible dashboard improvements, documentation updates, screenshot refreshes, beta programme changes, and user-facing security or privacy changes.

Private project notes, unpublished implementation details, internal workflow IDs, account credentials, provider tokens, raw diagnostics, and account-specific metrics must not be included in public release notes.

• Use exact dates when announcing public milestones.
• State whether a change is available, in private beta, planned, or roadmap.
• Link to the relevant documentation page when a release note changes user behavior.
• Keep engineering changelog detail in the central project documentation.