Start with the six core records and one defining rule: a client request does not become work until its commercial path is recorded.
01 · Core concepts
Six records, one connected history.
ScopeKeep is app-centered. Commercial terms, support capacity, client requests, approved work, payments, and delivery evidence remain connected to the software they describe.
App
The software asset at the center of the client relationship.
Support plan
The versioned recurring coverage sold for support, hosting, maintenance, or capacity.
Request
Something the client wants or reports. It is not automatically a task.
Scope decision
The recorded commercial classification that determines the path forward.
Quote
A versioned offer for billable work, tied to the request and its exact scope.
Work and release
Authorized delivery and the client-readable proof of what shipped.
02 · Quick start
Run one complete support loop.
Create a provider workspace with your name, timezone, currency, and brand.
Add a client account and the app you built or manage.
Choose or create a support plan, then invite the right client roles.
Capture a real or test request and gather the information needed to decide scope.
Complete the Scope Check before creating approved work.
Publish a client-ready release when the authorized work ships.
03 · Scope Check
Decide what the request means commercially.
A Scope Check uses the request, app lifecycle, warranty, active plan version, available entitlements, exclusions, urgency, and human judgment to produce an auditable decision.
WarrantyA qualifying defect is covered by recorded warranty terms.
IncludedMaintenance or support is included in the active plan.
Use balanceThe request reserves available hours or credits.
QuoteNew or excess work receives a versioned commercial offer.
Separate projectThe ask is large enough to leave the support workflow.
UnsupportedThe provider declines with a clear, client-readable reason.
The invariant
Submitted requests remain intake records. Covered work is scheduled only after a confirmed Scope Check; billable work waits for the required quote acceptance and payment.
04 · Client boundaries
Simple for clients. Precise for providers.
Clients can see
What is included and what remains
Requests and plain-language status
Quotes, approvals, invoices, and payments
Client-ready releases and app health
Providers keep private
Internal notes and raw technical context
Team cost, margin, and private estimates
Unshared assignments and work items
Integration secrets and broad account access
05 · Billing model
Two billing relationships, never one blended ledger.
Platform billing
Provider → ScopeKeep
The provider pays ScopeKeep for its SaaS plan, seats, limits, and eligible add-ons.
Client billing
Client → Provider
The client pays the provider for builds, support plans, feature work, hosting, overage, or incident work.
06 · Security model
Authorization is layered.
Routes authenticate. Application services check permissions and state. Postgres RLS enforces workspace and client access. Private storage and realtime channels mirror those boundaries. UI visibility alone never grants or revokes access.Read the security overview
Ready to run the workflow?
Continue to the main application to create a provider workspace.