# SaaS project brief

Prepared by Atyuttama · Planning template · 16 October 2026

Use this brief to explain the first release and compare development proposals. Write “unknown” where a decision is still open. Complete it with the people who will use, approve and operate the product. A completed brief helps scope a discussion; it is not a delivery estimate or contract.

Use examples without customer records, personal information or credentials.

## 1. The first useful outcome

- Product or working name:
- Who will use it first:
- The task they currently struggle to complete:
- How they handle that task today:
- The first useful result the product should deliver:
- Who approves product decisions:
- Who will operate it after launch:

## 2. One complete workflow

Describe one user journey from input to checked result. Include an exception.

| Step | Person or system | Input or trigger | Expected result | What happens if it fails? |
| --- | --- | --- | --- | --- |
| Start | | | | |
| Main task | | | | |
| Review or approval | | | | |
| Complete | | | | |
| Exception | | | | |

What must be included in the first release?

What is deliberately excluded or deferred?

## 3. Frontend and backend responsibilities

- Screens needed to complete this workflow:
- Browser and device requirements:
- Existing design, brand assets or design work required:
- Data records and system actions behind each screen:
- Internal administration or support tasks:
- Existing product, prototype or code that needs review:
- Migration or import requirements:

For each requirement, identify whether the proposal includes design, frontend, backend, integration and verification. A screen list alone does not describe the whole product.

## 4. Workspaces, people and permissions

| Role | Workspace or data it can access | Actions it can take | Actions requiring approval |
| --- | --- | --- | --- |
| Customer user | | | |
| Customer administrator | | | |
| Internal support or operations | | | |

- How people join, leave or change roles:
- How one customer's data is separated from another's:
- Sign-in, account recovery and any SSO requirements:
- Export and deletion requirements:

## 5. Plans and billing, if required

- Billing provider or existing billing system:
- Plans and the access each plan includes:
- Trial behavior:
- Upgrade and downgrade behavior:
- Payment-failure behavior:
- Cancellation and access-expiry behavior:
- Usage limits or metering:
- Who handles billing exceptions:

Mark a requirement “not needed” if it is outside the first release.

## 6. Connected systems and data

| System | Read or change what? | API/access owner | Provider limits or fees | Failure or retry behavior |
| --- | --- | --- | --- | --- |
| | | | | |
| | | | | |

- Source of truth for each important record:
- Duplicate handling and conflict resolution:
- Data quality or missing fields:
- Sample inputs available for review:
- Access that must be arranged before development:

## 7. AI behavior, if required

- Task where AI is expected to help:
- Approved knowledge sources and who maintains them:
- Which users may access which sources:
- Expected behavior when a source is missing, outdated or conflicting:
- Permitted tool actions:
- Actions that require human confirmation:
- Retention, provider and deployment requirements to review:
- Evaluation examples and who judges them:
- Usage or cost limits to agree:

## 8. Acceptance examples

Agree observable results before accepting a release. Use representative examples, including failures and permission boundaries.

| Scenario | Starting data and role | Expected result | Evidence or check | Reviewer |
| --- | --- | --- | --- | --- |
| Normal completion | | | | |
| Empty or missing input | | | | |
| User without permission | | | | |
| Integration unavailable | | | | |
| Duplicate or retry | | | | |
| Billing state change, if used | | | | |
| Unanswered AI request, if used | | | | |

## 9. Launch and operating constraints

- Target launch window and why it matters:
- Known dependencies or decisions that could move it:
- Initial users, data volumes and expected peak usage:
- Performance and accessibility expectations to agree:
- Timezone, language and currency requirements:
- Budget range, if known (optional):
- Development budget versus ongoing provider/infrastructure budget:
- Who reviews security, data access and release readiness:

## 10. Ownership and handover

Ask each proposal to state:

- Who owns and controls source repositories, domains and provider accounts.
- Which environments and deployment setup are included.
- What operating documentation and training are included.
- Who monitors failures, usage and provider costs.
- What maintenance or support is included, with its duration and limits.
- How access and ownership will be handed over.
- What is excluded and how later changes are estimated.

## Compare proposals on the same scope

| Question | Proposal A | Proposal B | Still unclear |
| --- | --- | --- | --- |
| Does the first workflow complete a useful task? | | | |
| Are design, frontend and backend responsibilities explicit? | | | |
| Are permissions, billing states and integrations covered? | | | |
| Are exclusions and dependencies stated? | | | |
| Are acceptance examples and reviewers agreed? | | | |
| Are provider costs and operating ownership visible? | | | |
| Is there relevant work to inspect and discuss? | | | |

## Discuss the brief

Atyuttama designs and builds SaaS products, business applications and AI workflows.

- SaaS service: https://www.atyuttama.com/services/web-development/saas-development
- Product design and development example: https://www.atyuttama.com/blog/heyrik-ai-voice-agents-product-case-study
- Project discussion: https://www.atyuttama.com/contact

Share a concise, non-sensitive summary first. Timelines, costs, responsibilities and acceptance criteria are agreed after scope review.