A Reusable PRD Framework for Standard SaaS Features

Here is something nobody tells you when you start building a SaaS product: most of what you build has nothing to do with your actual product idea.

I realised this while working through a plans folder for a product I was building. I had over 60 individual planning documents. When I sat down and sorted through them, I found that roughly half covered features every SaaS needs regardless of what problem it solves. Authentication. Billing. Email flows. Legal pages. Error tracking. Onboarding. These are not product-specific features. They are table stakes for any subscription-based web application.

That observation led me to pull all of those generic documents out and turn them into a single reusable framework. The idea is simple: next time I start a SaaS, I copy this template, delete anything that does not apply, fill in the product-specific sections, and I have a complete PRD without spending two weeks documenting things I have already figured out.

This article shares that framework. It is structured as a checklist you can copy directly.

If you want to understand how this fits into a broader planning process, I wrote about writing a project spec before development starts in the Project Spec article. A PRD and a project spec serve different purposes, but they work well together.

Why Standard SaaS Features Still Need Documentation

You might wonder why you need to document things that feel obvious. Authentication is authentication. Stripe is Stripe. Why write it down?

Because "obvious" features still have real decisions inside them. Do you support OAuth, or just email and password, or both? If both, what happens when a user tries to create an account with an email that already exists via GitHub OAuth? Which subscription tiers do you offer, and what is gated behind each one? What emails fire when a payment fails, and what happens if the user does not update their card?

These are not product-specific questions, but they still have answers that vary from project to project. Writing them down early means you stop relitigating them in your head every time you sit down to build a feature. The documentation is not for the obvious part. It is for all the edge cases hiding underneath.

The Framework

What follows is the full checklist of standard SaaS features, organised into sections. For each area I have included the key decisions and sub-features you need to document. Think of this as a fill-in-the-blanks template: copy it, delete anything that does not apply, and add your product-specific requirements around it.

Authentication

Every SaaS needs a way for users to sign in. The decisions here ripple through a lot of other features, so get them sorted early.

Email and password authentication
OAuth providers (GitHub, Google — pick the ones that match your audience)
Account creation conflict handling (e.g., user signs up with Google using an email that already has a password account)
Password reset flow
Email verification on signup
Session management and expiry
API token authentication (if you offer an API)
Rate limiting on login attempts
Two-factor authentication: TOTP via authenticator app, backup recovery codes, whether it is optional or enforced per tier
SSO/SAML for enterprise: which identity providers to support (Okta, Azure AD, Google Workspace), just-in-time provisioning, forced SSO enforcement at the organisation level

Team and Organisation Management

This is the section most solo-founder PRDs leave out until it is too late. If your product is used by more than one person at a company, you need it from day one — it touches billing, authentication, and onboarding simultaneously, and retrofitting it is painful.

Organisation creation on signup (or separate step after signup?)
Inviting team members by email
Invite flow: what happens if the invited email already has an account vs. is new to the platform
Roles and permissions (at minimum: owner, admin, member — define what each role can and cannot do)
Seat-based billing if applicable: what happens when a member is added beyond the plan's seat limit
Removing members and what access they lose immediately
Transferring ownership of the organisation
Leaving an organisation
Organisation settings: name, logo, billing contact

Subscription Tiers and Billing

This is where most of the product decisions live, so the template is deliberately light here. Fill in the specifics for your product.

Tier structure to define:

Free tier: what is included, what are the limits
Paid tiers: names, prices, billing intervals (monthly/annual), feature differences
Enterprise tier: custom pricing, any SSO or compliance requirements

Billing infrastructure to document:

Payment provider (Stripe is the default for most)
Free trial length and what happens at the end
Upgrade and downgrade behaviour
Cancellation flow and access after cancellation
Failed payment handling and retry logic
Data retention after cancellation

Feature gating decisions:

For each feature in your product, decide which tiers can access it. Document what happens when a free user hits a limit: do they see an upgrade prompt, get an error, or get gracefully degraded functionality?

Email Flows

Every SaaS needs a predictable set of transactional emails. These are easy to forget until a user complains they never got a welcome email.

Welcome email on signup (make sure this fires for both email/password and OAuth signups — they are separate code paths)
Password reset confirmation
Email verification
Team invitation email (separate from welcome — sent to an existing user vs. a new one)
Subscription created confirmation
Subscription cancelled confirmation
Subscription renewed confirmation
Payment failed notification
Trial ending soon warning (typically 3 and 7 days before expiry)
Subscription resumed confirmation
Account deletion confirmation

For each email, document the trigger, the recipient, the subject line, and a rough summary of the content. You do not need the final copy at PRD stage, but knowing the email needs to exist prevents it getting missed.

Legal and Compliance Pages

You need these in place before you can accept payments. Non-negotiable.

Terms of Service
Privacy Policy
Cookie Policy
Acceptable Use Policy

Document what platform you will use to host these (some teams use Termly or a similar service; others write their own), and flag whether you need a GDPR-compliant cookie consent banner.

User Account Settings

Often treated as an afterthought and shipped half-finished. Define the scope upfront.

Profile editing: name, avatar
Email address change (decision: re-verify new address before switching? notify the old address?)
Password change
Connected OAuth accounts: link and unlink providers
Two-factor authentication setup and recovery code regeneration
Active sessions: view all and revoke individual sessions
Notification preferences (see Notifications section)
Account deletion and data export request (see Data Export section)

The account deletion flow alone has more edge cases than it looks: what happens to team-owned resources? Can a user delete their account while they are the only owner of an organisation?

Notifications

Decide early what your notification system looks like, because it affects schema design, email infrastructure, and the account settings page.

In-app notification centre: bell icon, unread count, mark as read, mark all as read
Notification types: system alerts, billing events, team activity — the specifics depend on your product
Per-type preferences: email, in-app, or both, configurable per user
Real-time delivery if applicable: websockets, server-sent events, or polling
Notification retention period and cleanup

Data Export and Privacy

Required for GDPR compliance (right of portability and right of erasure) and increasingly expected by users regardless of regulation.

Data export request: what data is included, format (JSON, CSV, or both), delivery method (direct download or email with link)
Async generation for large exports: queue the job, email the user when the archive is ready
Account and data deletion: permanent deletion vs. soft delete with a retention window
Deletion scope: what gets deleted, what gets anonymised, what gets retained for legal or billing reasons
Data processing agreement (DPA) for B2B customers
Privacy settings page if applicable

API and Webhooks

If you plan to offer a public API or allow users to receive events from your platform, document this before you start building. API design decisions are expensive to reverse.

API key management: create, name, rotate, revoke
API key scopes and permissions
Rate limiting per key and per tier
API versioning strategy (version in URL path, header-based, etc.)
Public API documentation (OpenAPI spec, Swagger UI, or hand-written docs)
Outbound webhooks: events users can subscribe to, payload format, delivery guarantees, retry logic, secret signing for payload verification
Webhook delivery logs and debugging tools

Audit Log

Often the first thing an enterprise customer asks for during a sales call, and awkward to add after the fact.

Events to log: authentication events, billing changes, team membership changes, admin actions, data access for sensitive products
Retention period: and whether enterprise tier gets a longer window
Access: owner only, all admins, or configurable per role
Export format
Tamper-evidence: append-only log, signed entries, or third-party immutable log service

Infrastructure and Monitoring

These are often an afterthought. They should not be.

Error tracking (Sentry covers both backend and frontend JS — document whether you want both)
Health check endpoint at /health or similar
Uptime monitoring (Betterstack, Better Uptime, Pingdom — pick one)
Public status page, ideally hosted separately from your main app so it stays up when your app is down
Email deliverability configuration: SPF, DKIM, and DMARC records
Analytics (Plausible is privacy-friendly and simple; PostHog if you want session recordings and funnels)
Log aggregation if you need it

Customer Support

Decide early how you will handle support requests, before your first paying customer asks a question you are not ready to answer.

Support channel (email, live chat widget, or both)
Helpdesk tool if using one (Crisp, Intercom, Zendesk, or a simple shared inbox)
Whether you will surface documentation inside the app or just link out to external docs
SLA expectations per tier (Enterprise usually gets faster responses)

Onboarding Flow

The onboarding experience for a new user who has just signed up. This is product-specific in content but generic in structure.

Empty state screens for the main feature areas
Getting-started guide or checklist
Welcome banner or modal with dismissal behaviour
First-run example content (give users something concrete to try on their first visit)
Onboarding email sequence if applicable

Admin Panel

Unless you plan to run everything from the database command line, you need some kind of internal admin interface.

User management (view, impersonate, ban)
Subscription management (manually override tiers, extend trials)
Feature flag management
Basic analytics dashboard

Document what tool you will use. Filament is a solid choice for Laravel projects. For other stacks, pick something that does not require a full custom build.

Feature Flags

Useful for gradual rollouts and for giving beta access to specific users. Worth setting up early even if you do not use it immediately. See Feature Toggles for a deeper look at the different types and when to use them.

Flag management system (Laravel Pennant, Unleash, or a simple database table)
Per-user flag overrides
Per-tier flag defaults

Custom Domains

Relevant if your product serves user-facing content under a customer's own branding — portals, dashboards, generated sites, or white-labelled instances.

Subdomain option (e.g., acme.yourapp.com) vs. full custom domain (e.g., app.acme.com)
DNS verification method: CNAME record or TXT record
SSL certificate provisioning: Let's Encrypt via cert-manager, or your hosting platform's built-in handling
What happens when verification fails or a certificate expires
Which tiers can use custom domains

White-Labelling

Removing your branding for enterprise customers. Often paired with custom domains.

Scope: logo and product name only, full UI rebranding, or transactional emails sent from their domain
Custom email from-address and reply-to (requires configuring SPF and DKIM for the customer's domain)
Removing "Powered by" references across the UI and emails
Whether white-label is a tier feature or a separately priced add-on

Internationalisation

If you are intentionally targeting a single locale, document that as an explicit decision rather than leaving it as an oversight. If you might expand, decide how much groundwork to lay now.

Language support: even English-only products should avoid hardcoding strings in ways that make translation painful later
Timezone handling: store everything in UTC, display in the user's local timezone — decide how you capture the user's timezone preference
Currency and pricing: single currency vs. localised pricing per region
Date and number format localisation
Right-to-left language support if applicable

Marketing and Growth Infrastructure

Not strictly product features, but they need to be planned and built.

Launch and go-to-market plan (timeline, target segments, and primary channels)
Public documentation site or docs section
Blog (even a simple one helps with SEO over time)
Custom error pages (404 and 500 at minimum — branded, not the framework default)
SEO fundamentals: meta tags, Open Graph, sitemap, robots.txt
Changelog page (users want to know what has changed)
Social media presence (at least claim your handles early)
Customer feedback collection (a simple form or a tool like Canny)
Referral and affiliate programme: referral credit vs. cash payout, tracking mechanism, minimum payout threshold, fraud prevention

Comparison pages and integration guides come later, but it is worth noting them in the PRD so they end up on the roadmap rather than getting indefinitely deferred.

How to Use This Framework

Copy the relevant sections into your PRD for the new product. Fill in the specifics for anything that has a decision to make. Delete sections that genuinely do not apply (a B2B tool with annual contracts only has no trial ending email, for instance).

Then add your product-specific sections after the standard ones. Those are the features that are unique to what you are building. The standard sections above will look roughly the same regardless of what you are building.

The goal is to get to the product-specific work faster. Documenting authentication for the fourth time from scratch is not a good use of your planning time.