DashForDevsDocs
DocsNewsAPI v1
dashfordevs.comSign in

© 2026 DashForDevs

DocsNewsdashfordevs.comLegalStatus
DocsUse CasesThe agency dashboard
Introduction
Getting Started
Authentication
Products
Categories
Cart
Checkout
Blog
Reviews
Webhooks
Customers
Orders
Inventory
Shipping
Discounts
Affiliates
Email
Media & Files
Analytics & Tracking
Locations
Tax
Global Data
SEO
Error Handling
Geography
Finance
Automations
Page Types
Surveys
Billing & Subscriptions
Storefront Payments
SDK Reference
REST API
Storefront Architecture
Notifications
Security
Team & Permissions
Migrations & Import
Calendar & Appointments
Contact Forms
AI Bots
Dashboard API
Deployment
Changelog
Troubleshooting
Recipes
CLI & Deployment
Image Pipeline
White-label Platforms
Records Engine
Platform Modules
Platform Security
Site Keys & Client Sites
Use Cases
The agency dashboardThe service businessThe site fleetData-sensitive verticals
Operations

The agency dashboard

A web/SEO agency: staff dashboard, client portal, and a fleet of client sites.

Updated July 26, 2026

On this page
  • The shape
  • The spine
  • A client's lifecycle, end to end
  • What makes it work as a product

The shape

This is the fullest use of the system, and the pattern production agency platforms run today. Grants: nearly everything — records, customers, projects, websites, forms, contacts, media, inventory, pages, insights, invoices, expenses, tickets, planner, calendar, team, email, logs.

Two front ends from one codebase: a staff dashboard (/dashboard) and a client portal (/client), both driven by the module grant, plus a marketing site — and then each client's own website on the site SDK.

The spine

Customer → project → website. A customer owns projects; each project carries exactly one website; everything else hangs off the project. The staff project page composes every module that touches that client into one set of tabs: locations, to-dos (the planner scoped to the project), the website and its deploy panel, the product catalog, the site's lead inbox, the blog, files, expenses, site keys, a notes board, settings.

A client's lifecycle, end to end

  1. Booked — a guest books a first call from the marketing site (calendar module); staff confirm and convert the guest into a customer.
  2. Onboarded — the customer gets a portal invite; onboarding collects their business profile into a locations record.
  3. Intake — staff assign a questionnaire (forms module) to the project; the portal nags the client — red task, deep-linked email — until it's answered once.
  4. Built — a project in in-build; the site is a Next.js app on the site SDK, reading content, files, products and locations from the platform.
  5. Deployed — repo + branch + instance size → DigitalOcean app, DNS pointed via Cloudflare, keys injected automatically; pushes to main auto-deploy.
  6. Live — the site's contact form lands leads in the project's inbox and the client's portal; the insights beacon feeds the site dashboard; uptime, costs and logs are visible to staff.
  7. Billed — invoices to the client (invoices module), costs on their behalf tracked as expenses, infrastructure cost on the Servers page.

What makes it work as a product

  • The portal scopes everything by the signed-in customer at the data layer — a guessed project id behaves like a missing one.
  • Client team seats let the client bring their assistant without becoming two customers.
  • Per-site keys make client offboarding a revoke, not a migration.
PreviousBuilding a paired site SDKNextThe service business

On this page

  • The shape
  • The spine
  • A client's lifecycle, end to end
  • What makes it work as a product