Trackpal dossier

Product summary

Fact: Trackpal is a private-beta KPI monitoring and scorecard app for small businesses and marketing agencies.

Fact: Its core product promise is: connect accounts, pick a template, and know whether key numbers are on track.

Intended users

• Marketing agencies managing client spend and budget pacing.
• Small ecommerce businesses wanting a simple store pulse dashboard.
• Scott as private-beta operator managing invites, provider setup, sync health, and feature rollout.

Problem being solved

Small agencies and store owners do not want to build BI dashboards. They need a curated scorecard that shows which clients or metrics need attention, whether data is stale, and what changed in plain language.

Current status

Fact: The generated dossier still says Trackpal is planned and in phase-00-planning-and-repo-setup.

Fact: The current README and package manifests describe a first private-beta implementation slice with customer web, admin web, sync Worker, shared core contracts, Supabase migrations, beta preflight scripts, and UI smoke tests.

Inference: Treat Trackpal as early implemented/private-beta, with stale generated metadata that should be refreshed in the Trackpal repo.

Known aims and strategic intent

• Avoid becoming a generic dashboard builder.
• Start with invite-code gated private beta rather than public self-serve.
• Lead with Agency Spend Monitor and Client Budget Pacing.
• Use demo data before live integrations to validate product flow.
• Keep dashboards template-driven and metric-definition aware.
• Keep admin operations separate and protected by Cloudflare Access.

Built functionality

Fact: The README describes:

• Customer app rendering signup, login, invite screens, protected /app/* routes, onboarding, workspace/client views, template catalogue, alerts, connected account health, settings, and selected-template demo dashboards.
• Admin app rendering invite, provider, secret/config status, demo, sync, template, and feature-flag operations surfaces.
• Sync Worker with health and bounded enqueue endpoints for demo/manual/provider sync jobs.
• Shared domain, beta-flow, template, metric, alert, demo-data, dashboard, provider, invite, sync, and admin contracts in core.
• Supabase migrations.
• Read-only beta connector foundations for Google Ads, Shopify, and Klaviyo.
• Guarded stubs for Meta Ads and Xero.

Key apps, workers, packages, and services

Surface	Role
apps/websites/web	Customer-facing private-beta KPI app.
apps/websites/admin	Internal operations app protected by Cloudflare Access.
apps/workers/sync-worker	Cloudflare Worker for sync health and bounded enqueue endpoints.
packages/core	Shared Trackpal domain contracts, templates, metric definitions, calculations, demo data, alerts, providers, and admin models.
db/supabase/migrations	Supabase schema migrations.

Data sources and integrations

Fact: V1 integration ordering is demo data, manual budgets/imports, Google Ads spend sync, Meta Ads spend sync, Shopify store pulse, Klaviyo email revenue, and later Xero monthly P&L mapping.

Fact: Google Ads, Shopify, and Klaviyo have read-only beta connector foundations according to the README; Meta Ads and Xero remain guarded stubs.

Fact: Runtime providers include Cloudflare Workers, Cloudflare Queues/Cron, Supabase Postgres/Auth, and Cloudflare Access for admin.

Deployment and runtime assumptions

• Customer and admin apps are Next.js App Router surfaces deployed through OpenNext on Cloudflare Workers.
• Sync jobs initially fit Cloudflare Cron/Queues/Worker execution.
• Supabase Postgres/Auth provides multi-tenant data and authentication.
• Tokens and service-role operations stay server-side.
• Admin app uses Cloudflare Access, not a separate app-level admin login.

Reusable capabilities

Capability	Reuse potential	Notes
Template-driven dashboard renderer	High	Reusable for DataStitcher apps, admin dashboards, and future SaaS tools.
Metric catalogue and snapshot model	Medium to high	Useful wherever high-level metrics need source/freshness/definition context.
Provider registry and secret-status admin	High	Similar needs appear in SiteIntel, DataStitcher, Project Hub, and BigQuery Atlas.
Demo data generator	Medium	Useful for private beta flows and product demos.
Invite-code beta access flow	Medium	Reusable for other private beta SaaS products.
Sync health/run summaries	High	Common operational surface across data and integration products.

Notable design patterns

• Templates define dashboard structure, sections, cards, tables, alerts, summaries, empty states, and setup prompts.
• Page components resolve templates and metrics into view models, then render reusable sections.
• Admin app displays secret/config status without raw values.
• Provider rollout can be disabled, beta, enabled, needs_config, or blocked.
• Live integrations are read-only and focused on top-level metrics.

Dependencies on other products or Meridian tooling

Fact: Trackpal uses Meridian config/deployment conventions, shared deployment tooling, generated operations docs, and package scripts.

Inference: Trackpal should be the first proving ground for reusable template dashboard contracts and provider/secret-status admin surfaces.

Risks and unknowns

• Generated dossier metadata is stale relative to README/package evidence.
• Live provider APIs have changing scopes, quotas, approval processes, and app-review requirements.
• OAuth and service-role secrets must stay server-side.
• It can easily drift into a generic BI/dashboard builder if template boundaries are ignored.
• Billing is deliberately out of MVP scope.

Near-term next steps

• Refresh Trackpal's metadata/project-dossier.json to match current implementation.
• Keep Agency Spend Monitor excellent before adding too many templates.
• Verify current official provider docs before expanding live integrations.
• Continue tests around template resolution, metric calculations, sync health, and admin secret-status behaviour.

Longer-term product potential

Opportunity: Trackpal has a practical SaaS wedge through agency budget pacing and simple store pulse scorecards.

Opportunity: The template and metric system could become a reusable dashboard engine for future Meridian products, but only after two product surfaces prove the abstraction.

AI notes

• Do not add billing in early private beta unless explicitly requested.
• Do not build campaign write actions.
• Do not hardcode one dashboard per template when configuration can express it.
• Never expose raw OAuth tokens, API keys, or Supabase service-role keys to browser-readable state.
• Verify current provider API docs before implementing live integrations.

Source coverage

Coverage is strong for product planning, template/metric/admin boundaries, current package/app shape, and deployable units. Product metadata is stale and should be updated at source.

Sources consulted

• projects/trackpal/README.md
• projects/trackpal/apps/websites/docs/metadata/project-dossier.json
• projects/trackpal/docs/product/00-executive-summary.md
• projects/trackpal/docs/product/03-mvp-scope.md
• projects/trackpal/docs/product/06-data-model.md
• projects/trackpal/docs/product/07-template-system.md
• projects/trackpal/docs/product/12-integrations-strategy.md
• projects/trackpal/docs/product/15-architecture-stack.md
• projects/trackpal/docs/product/20-admin-operations-app.md
• projects/trackpal/docs/product/21-dashboard-configuration-and-design.md
• projects/trackpal/docs/product/reference/metric-catalog.md
• projects/trackpal/docs/product/reference/template-catalog.md
• projects/trackpal/docs/status/project-cockpit.mdx
• projects/trackpal/docs/operations/deployable-units.mdx
• projects/trackpal/package.json
• projects/trackpal/apps/websites/web/package.json
• projects/trackpal/apps/websites/admin/package.json
• projects/trackpal/apps/workers/sync-worker/package.json
• projects/trackpal/packages/core/package.json