Specly
Home

Compose Hybrid Spec

Pick features from multiple specs and mix them into a single build. Notifications from Slack + payments from e-commerce? Go.

Source specs

SaaS Starter10 features
Audit Loggingmedium

What to Log*

Sign-in, sign-out, failed login, password reset, MFA enrollment, session revocation.
Role changes, permission grants, user invites, impersonation sessions, configuration changes.
Record who viewed or exported which records.
Record state changes to business records with before/after values.

Storage Backend*

An `audit_log` table with insert-only permissions; never updated or deleted.
Stream audit events to S3 Object Lock, AWS QLDB, or a dedicated audit platform.
Primary audit storage lives in the customer or your SIEM.

User-facing Surface

A searchable, filterable log in your admin panel showing recent events.
A paginated API or scheduled export letting customers ingest audit data themselves.

Tradeoffs

CostData access logging enabled

Read amplification — every authenticated read produces a log write

ComplexityImmutable store chosen

Two storage systems to operate and keep in sync; queries may need to federate

ComplexityAppend-only table only

Tamper-evidence relies on DB role permissions — insufficient for some compliance regimes

fromSaaS Starter
Background Jobs & Queuesmedium

Queue Backend*

Jobs are rows in a Postgres/SQLite table; workers SELECT FOR UPDATE SKIP LOCKED.
Durable queue on Redis with mature worker libraries.
Purpose-built broker with durability, backpressure, and multi-consumer support.

Required Capabilities*

Recurring jobs (nightly emails, weekly reports) defined in code or a UI.
Enqueue a job to run at a specific future timestamp (trial expiry, reminder emails).
Separate queues for high-priority (user-triggered exports) vs bulk (nightly batches).
Throttle jobs that call rate-limited external APIs.

Failure & Durability*

Failed jobs retry with increasing delay; after N attempts move to a dead-letter queue for human review.
Jobs are enqueued inside DB transactions; handlers are idempotent so safe retries do not duplicate effects.

Tradeoffs

ScalabilityDatabase-backed queue at high volume

Primary DB absorbs queue write load; row-level locks contend with application queries

ComplexityRedis-backed queue without outbox

Enqueue happens outside DB transaction — jobs can run for state that was rolled back

ComplexityTransactional outbox chosen

Additional table, polling worker, and idempotency discipline — the payoff is no duplicated side effects

fromSaaS Starter
Multi-tenancy & Workspaceshigh

Data Isolation Model*

Every table has a tenant_id column; every query filters on it.
One Postgres schema per tenant; tables are replicated across schemas.
Each tenant gets an isolated database (sometimes isolated VPC).

Tenant Identification*

Tenant context derived from hostname; clean URLs and cookie scoping.
Tenant context read from the URL path.
One URL; user picks active tenant after login and it persists in their session.

Per-tenant Configuration

Enable/disable features for specific tenants (beta access, custom enterprise features).
Logo, colors, and optionally custom domain in tenant-facing UI.
Auth policy, session duration, data retention, allowed domains — configured per tenant.

Tradeoffs

ComplexityShared DB, shared schema

Cheapest ops and easiest queries, but a single missed tenant_id filter is a data leak

CostDatabase-per-tenant

Operational cost scales with tenant count; migrations must run against every tenant DB

ComplexitySubdomain routing

Wildcard TLS cert and DNS configuration required; vanity domains compound that

ComplexityPer-tenant feature flags

Testing surface expands — every change must consider flag combinations and tenant configs

fromSaaS Starter
Notificationsmedium

Delivery Method*

Push notifications instantly as events occur
Client polls server on a fixed interval
Send email when user is offline
Native push notifications for mobile apps

User Control

Simple global on/off toggle
Separate preferences per event category
Highly granular per-item preferences

Tradeoffs

CostReal-time delivery selected

Requires persistent connection infrastructure (e.g. Redis pub/sub, WebSocket server)

LatencyPolling selected

Higher server request volume; notifications may lag by poll interval

ComplexityMobile push selected

Requires APNs/FCM credentials and certificate management

ComplexityPer-source granularity selected

Significantly more complex preference storage and UI

fromSaaS Starter
Onboarding & Activationmedium

Onboarding Format*

No dedicated onboarding UI — every empty screen contains a clear primary action pointing to the next step.
A dismissible checklist ("Invite teammate • Create project • Connect integration") visible until complete.
Step-through overlays point at UI elements on first use.
User cannot access the product until they complete N configuration screens.

Personalization Signals

Ask one or two questions to route the user to a tailored first experience.
Present starter templates ('Blank', 'Team docs', 'Marketing site') as the first interaction.
Every new workspace starts with an example project the user can play with.

Activation Support

Email nudges when a user signed up but has not yet hit the key activation action (e.g. created their first project).
A persistent help button that opens relevant docs or a short walkthrough based on the current page.
Intercom-style chat surface active for new users in their first few days.

Tradeoffs

UXSetup wizard as format

Controls first-experience but introduces sign-up drop-off proportional to wizard length

ComplexityActivation emails enabled

Requires event tracking + scheduled jobs + segmentation infrastructure

CostLive chat during onboarding

Staffing cost scales with signup volume — not viable for self-serve products below a certain ACV

fromSaaS Starter
Payments & Billinghigh

Billing Model*

Single charge per product or service
Monthly or annual recurring billing
Charge based on consumption (API calls, seats, etc.)

Payment Processor*

Full-featured; best-in-class developer experience
Merchant of record; handles VAT/tax automatically

Tradeoffs

ComplexitySubscription billing selected

Requires handling trial periods, dunning, proration, and cancellation flows

ComplexityUsage-based billing selected

Must instrument every billable action and send metered events to billing provider

UXPaddle selected

Less customizable checkout; Paddle acts as legal seller so you avoid VAT registration

fromSaaS Starter
Rate Limiting & Abuse Preventionmedium

Rate Limit Algorithm*

Count requests per user per minute; reset at the minute boundary.
Counts over a rolling window to eliminate boundary bursts.
Each identity has a bucket that refills at a steady rate; each request consumes a token.

What to Limit By*

Limits keyed on client IP.
Limits keyed on user ID or API key.
Expensive endpoints (search, export) get lower limits than cheap ones.
Aggregate limit across all users in a workspace.

Abuse Prevention Layer

hCaptcha / Turnstile on signup, login, and password reset — triggered on threshold breach, not every request.
ML-driven client fingerprinting to score requests as human/bot before routing.
Cloudflare, AWS WAF, or Fastly with OWASP and bot rule packs in front of your origin.

Response Behavior*

Return HTTP 429 with Retry-After, X-RateLimit-Limit, and X-RateLimit-Remaining so clients back off correctly.
After threshold, delay responses by seconds instead of returning 429.

Tradeoffs

UXPer-IP limits only

False positives behind corporate NATs; attackers bypass with rotating proxies

ScalabilityPer-tenant limits enabled

Noisy-neighbor protection — one tenant cannot starve others

CostToken bucket chosen

Allows bursts but requires a per-identity bucket state in Redis — higher memory footprint

LatencyWAF added in front

Meaningful latency cost at the edge if the WAF is geographically distant from users

fromSaaS Starter
Roles & Permissionshigh

Authorization Model*

A fixed enum on the user record gates admin-only routes.
Users are assigned roles; roles bundle permissions; code checks permissions, not roles.
Permissions derived from attributes or graph relationships (owner, member, parent folder, etc.).

Permission Scope*

Permissions apply across the entire product.
A user has different roles in different workspaces or organizations.
Access lives on the resource itself — share a single document with specific users.

Custom Role Management

Roles (admin / member / viewer) are defined in code; customers cannot change them.
Admins can create roles and assign permissions.

Tradeoffs

ComplexitySimple roles chosen

Fast to build but every 'special case' access rule becomes bespoke code that's hard to audit

ComplexityABAC / ReBAC chosen

Requires a policy engine and relationship store kept in sync with primary data

LatencyPer-resource scope enabled

Every list/read query must filter by ACL — expect query-plan work and caching investment

CostCustomer-defined roles enabled

Support load increases substantially — each customer now has a unique permission configuration

fromSaaS Starter
Transactional Emailmedium

Delivery Provider*

Third-party email API with APIs, templates, and deliverability monitoring.
Cheapest at volume; minimal tooling built in.
Your own MTA (Postfix, Haraka) on your own IPs.

Deliverability Setup*

Authenticate your sending domain; publish a DMARC policy; monitor reports.
Consume bounce and spam-complaint webhooks; suppress invalid or unsubscribed addresses.
Different sending domains / IPs for product email vs marketing campaigns.
Your own sending IP instead of a shared pool.

Templating Approach*

Email templates live in your repo, reviewed and tested like any other code.
Templates managed in the provider dashboard; non-engineers can edit.
Single service manages email, in-app, SMS, and push with per-user preferences.

Tradeoffs

CostManaged provider chosen

Vendor cost scales with volume; deliverability expertise comes included

ComplexitySES chosen

Low per-email cost but you own deliverability operations (reputation, bounces, suppression)

ComplexitySeparate streams for marketing vs transactional

Two sending configurations and domains to maintain — worth it for deliverability isolation

fromSaaS Starter
User System & Authlow

Authentication Methods*

Classic credential-based login
One-click login via email link
Sign in with Google
Sign in with GitHub
Enterprise single sign-on

Access Control*

No roles — every authenticated user has the same access
Simple two-tier access control
Custom roles with fine-grained permissions

Multi-factor Authentication

Single-factor only
Time-based one-time passwords

Tradeoffs

ComplexityOAuth providers added

Each provider requires an OAuth app registration and key rotation policy

ComplexitySAML/SSO selected

Requires IdP partnership and XML-based protocol handling; significant integration work

ComplexityRBAC selected

Permission checks must be applied consistently across every data access path

fromSaaS Starter

Summary

10 of 10 composed features enabled

Pulled from 1 source spec

Effort Estimate

10+ weeks

5+ engineers