Build: CRM Platform
Toggle features and choose options to customize your spec
Preset
Authentication Methods*
Access Control*
Multi-factor Authentication
Tradeoffs
Each provider requires an OAuth app registration and key rotation policy
Requires IdP partnership and XML-based protocol handling; significant integration work
Permission checks must be applied consistently across every data access path
Search Approach*
Search Scope*
Tradeoffs
Requires FTS index maintenance; adds write-time overhead
Embedding generation adds latency and API cost per indexed document
Results must be unified and ranked across disparate data models
Delivery Method*
User Control
Tradeoffs
Requires persistent connection infrastructure (e.g. Redis pub/sub, WebSocket server)
Higher server request volume; notifications may lag by poll interval
Requires APNs/FCM credentials and certificate management
Significantly more complex preference storage and UI
Authorization Model*
Permission Scope*
Custom Role Management
Tradeoffs
Fast to build but every 'special case' access rule becomes bespoke code that's hard to audit
Requires a policy engine and relationship store kept in sync with primary data
Every list/read query must filter by ACL — expect query-plan work and caching investment
Support load increases substantially — each customer now has a unique permission configuration
What to Log*
Storage Backend*
User-facing Surface
Tradeoffs
Read amplification — every authenticated read produces a log write
Two storage systems to operate and keep in sync; queries may need to federate
Tamper-evidence relies on DB role permissions — insufficient for some compliance regimes
Delivery Provider*
Deliverability Setup*
Templating Approach*
Tradeoffs
Vendor cost scales with volume; deliverability expertise comes included
Low per-email cost but you own deliverability operations (reputation, bounces, suppression)
Two sending configurations and domains to maintain — worth it for deliverability isolation
Onboarding Format*
Personalization Signals
Activation Support
Tradeoffs
Controls first-experience but introduces sign-up drop-off proportional to wizard length
Requires event tracking + scheduled jobs + segmentation infrastructure
Staffing cost scales with signup volume — not viable for self-serve products below a certain ACV
Summary
7 of 8 features enabled
Effort Estimate
10+ weeks
7 enabled features
Key Decisions
User System & Auth
Will this product be sold to businesses (B2B)?
If yes
Add SAML/SSO and RBAC. Enterprise procurement often requires both.
If no
Email + password plus one OAuth option covers 95% of consumer use cases.
User System & Auth
Is this a security-sensitive application?
If yes
Enable TOTP MFA. Consider making it mandatory for privileged users.
If no
MFA is optional — offer it but do not require it to reduce friction.
User System & Auth
Email+password, passwordless, or SSO-only?
If yes
Passwordless (magic links or passkeys) eliminates password reset tickets and credential stuffing risk.
If no
Keep email+password as a universal fallback — OAuth outages should not lock users out.
User System & Auth
Do you need social providers (Google, GitHub, Apple)?
If yes
Add Google for B2C breadth; add GitHub for developer tools; add Apple only if you ship iOS (App Store requires it when you offer other social login).
If no
Skip social OAuth and avoid the app registration / key rotation overhead.
User System & Auth
Do you need SCIM provisioning?
If yes
Add SCIM alongside SAML — enterprise IT uses it to auto-provision/deprovision employees and map group membership to roles.
If no
Manual invite flows are fine until your first enterprise customer asks for SCIM in a security review.
User System & Auth
Should MFA be required, optional, or risk-based?
If yes
Risk-based (step up MFA on new device, new IP, or sensitive actions) gives security without friction on every login.
If no
Offer MFA as optional first; require it only for admins or on privileged actions.
User System & Auth
Which MFA factors will you support (TOTP, SMS, WebAuthn/passkeys, hardware keys)?
If yes
Prefer WebAuthn/passkeys and TOTP. Avoid SMS as a primary factor — SIM swapping is a real threat.
If no
TOTP alone (Google Authenticator, Authy) covers the vast majority of users with minimal implementation cost.
User System & Auth
Do you need device fingerprinting or trusted-device flows?
If yes
Remember trusted devices for 30 days to skip MFA; challenge on new device or changed fingerprint.
If no
Re-prompt MFA on every login — simpler and safer for low-volume or highly sensitive apps.
User System & Auth
Offer passkey-only sign-in?
If yes
Passkeys eliminate passwords entirely — use WebAuthn with platform authenticators. Still keep an email recovery path for lost devices.
If no
Offer passkeys as an optional second factor; users without compatible devices keep using passwords.
User System & Auth
Support staff impersonation of user accounts?
If yes
Add an impersonation flow that logs both the staff identity and the target user, with a visible banner in the impersonated session.
If no
Skip impersonation — instead build admin-side read views and support tooling that do not require acting as the user.
User System & Auth
Captcha or bot detection on signup?
If yes
Add hCaptcha or Cloudflare Turnstile on signup and password reset — invisible challenges avoid user friction.
If no
Skip captcha for internal tools or invite-only products where bot signups are not a realistic threat.
User System & Auth
Use lockout or rate-limit throttling for credential stuffing?
If yes
Exponential rate limits per IP and per account — lockouts create support tickets and denial-of-service vectors via targeted lockout.
If no
If account takeover risk is low, a simple fixed rate limit (e.g., 10 attempts per 15 min) is sufficient.
User System & Auth
Allow multiple concurrent sessions per user?
If yes
Show active sessions in account settings with a revoke button — expected behavior for any multi-device product.
If no
Single-session apps (banking, compliance) should terminate old sessions on new login.
Search
Do users search by meaning, not just keywords?
If yes
Invest in semantic/vector search. Start with full-text and migrate.
If no
Full-text search covers keyword use cases at a fraction of the cost.
Search
DB full-text or a dedicated engine (Elasticsearch, Typesense, Algolia)?
If yes
Reach for a dedicated engine when DB FTS can't meet latency or ranking needs. Algolia for hosted DX, Typesense/Meilisearch for self-hosted.
If no
Start with SQLite FTS5 or Postgres tsvector — no extra service to run.
Search
Do users need faceted filtering (refine by category, tag, date range)?
If yes
Use a dedicated engine — faceting across millions of rows in Postgres FTS gets slow fast. Typesense and Algolia do this natively.
If no
Keyword-only over FTS is sufficient; add facets later.
Search
Do you need typo tolerance / fuzzy matching on short queries?
If yes
A dedicated engine (Typesense, Algolia, Meilisearch) gives this out of the box. DB FTS typo tolerance is weak.
If no
Strict matching is fine for structured queries and technical users.
Search
Will you support multiple languages with proper stemming?
If yes
Pick an engine with per-locale analyzers (Elasticsearch, Meilisearch). Postgres tsvector ships only a handful of language dictionaries.
If no
English-only tsvector or FTS5 is plenty.
Search
Do users expect personalized ranking (their clicks influence their results)?
If yes
Algolia or a custom scoring layer on top of an engine — personalization needs per-user signals, not just index weights.
If no
Use global relevance scoring (BM25) — simpler and predictable.
Search
Is autocomplete / instant search (as-you-type) part of the UX?
If yes
Pick Typesense, Algolia, or Meilisearch — all tuned for sub-50ms responses. Postgres FTS will feel sluggish here.
If no
Submit-driven search works against any backend.
Search
Do you need search analytics (popular queries, zero-result queries)?
If yes
Log queries + result counts separately; feed into your analytics pipeline. Algolia and Meilisearch expose this natively.
If no
Skip until product teams ask for it.
Search
Must results respect per-user permissions (ACL-aware)?
If yes
Index ACL identifiers alongside documents and filter at query time. Global cross-entity search is especially risky — validate before shipping.
If no
A flat index is simpler; use when all users see the same corpus.
Search
Do customers need custom synonyms and stop-words (domain vocabulary)?
If yes
A dedicated engine with synonym dictionaries (Algolia, Elasticsearch) — editable without re-indexing.
If no
Default analyzers work for general-purpose text.
Search
Do you need rule-based boosting (featured or sponsored results)?
If yes
Algolia has a dashboard for this; Elasticsearch supports function_score. Don't hand-roll on top of tsvector.
If no
Pure relevance ranking is cleaner.
Search
Is mobile bandwidth a constraint for search-as-you-type?
If yes
Debounce aggressively (~300ms), return tiny payloads, and consider a provider that supports partial-result responses.
If no
Desktop-grade instant search is fine; no special tuning needed.
Search
Must newly created content be searchable within seconds (near-real-time)?
If yes
Index on write into an engine with NRT support (Elasticsearch, Typesense). Budget for higher write amplification.
If no
Batch reindex every few minutes via background job — simpler and cheaper.
Search
Do users search across multiple indices / entity types in one query (federated)?
If yes
Global scope is required. Use Algolia multi-index search or aggregate in app code — plan ranking carefully.
If no
Per-resource search is simpler and faster.
Search
Do users need "did you mean" spell correction for empty-result queries?
If yes
Meilisearch and Algolia provide this out of the box. Ties naturally with zero-result analytics.
If no
Show filters and suggested queries instead; simpler to build.
Search
Should users be able to save searches or get alerts on new matches?
If yes
Store the query, schedule a job to re-run it, and diff results. Pair with the notifications module for delivery.
If no
Manual re-runs cover most use cases; skip the infra.
Notifications
Do users need to know about events immediately?
If yes
Use real-time delivery. Budget for WebSocket/SSE infrastructure.
If no
Polling is simpler and cheaper — pick an interval that matches your SLA.
Notifications
Is this a mobile-first product?
If yes
Add mobile push (APNs/FCM). Plan for certificate rotation.
If no
Skip mobile push; web notifications or email cover most cases.
Notifications
Do users often go offline and still need to receive notifications?
If yes
Add email fallback driven by a "last seen" timestamp. Send email only when the user has been offline >5 minutes to avoid spam.
If no
In-app real-time or polling is enough — email adds unsubscribe risk without upside.
Notifications
Will you send multiple notification types with different urgency levels?
If yes
Adopt per-type granularity so users can mute digests without muting security alerts. Define the taxonomy up front.
If no
A single all-or-nothing toggle is enough and avoids preference-UI bloat.
Notifications
Is notification volume high enough that users will complain about floods?
If yes
Batch similar notifications in a rolling window (e.g., "Alice and 12 others liked your post"). Entity + time-window grouping is the standard pattern.
If no
Deliver individually — grouping adds UI complexity that is not worth it at low volume.
Notifications
Are any notifications security-critical or financially sensitive?
If yes
Require at-least-once delivery with persistent storage and retry. Pair with email fallback for the highest-urgency classes.
If no
Best-effort (fire-and-forget) is fine for social and informational notifications.
Notifications
Do users have reasonable expectations of quiet hours / do-not-disturb?
If yes
Add a per-user quiet-hours window and a priority flag that lets critical alerts bypass it. Requires per-type granularity to know what is critical.
If no
Skip quiet hours — the added preference surface is not worth it for low-volume products.
Notifications
Do users need to mark notifications as read / track what they have seen?
If yes
Persist notifications with a read state. Consider cross-device read-state sync via a server-side timestamp or event log.
If no
Ephemeral toast-style notifications are simpler and appropriate for low-stakes alerts.
Notifications
Do you need delivery analytics (delivered, opened, clicked)?
If yes
Use a provider like Knock or Novu that tracks delivery funnel by channel. Essential if notifications drive revenue or retention KPIs.
If no
Skip the instrumentation — simple success/failure logs are enough.
Notifications
Do users have multiple devices (web + mobile + desktop)?
If yes
Sync read-state across devices via a server-side last-read timestamp. Without this, users see the same notification over and over.
If no
Device-local read state is simpler and avoids backend round-trips.
Notifications
Do you need SMS as a notification channel?
If yes
Use Twilio or Messagebird. Reserve SMS for high-priority alerts only — it is expensive per message and users churn fast on SMS spam.
If no
Skip SMS — push and email cover 99% of use cases at a fraction of the cost.
Notifications
Are some notifications purely in-app / ephemeral (toast-style)?
If yes
Deliver via SSE/WebSocket without persisting — no storage, no retry, no read-state UI. Good for "Saved", "Uploaded" feedback.
If no
All notifications go through the durable pipeline with read-state tracking.
Notifications
Do you need localized notification content (multi-language)?
If yes
Store notification templates with i18n keys and render per-recipient locale at send time. Avoid pre-rendered strings in the event.
If no
Hardcoded English strings are fine until you have non-English users.
Notifications
Do you have more than 5 notification types or expect to add more regularly?
If yes
Invest in a template engine (Knock, MJML, or Handlebars) with versioned templates rather than hardcoded message strings.
If no
Hardcoded message strings in the sender are simpler and fine for a small stable set.
Notifications
Do product/marketing teams need to preview and test-send notifications before release?
If yes
Build an internal preview tool with a test-recipient flag. Prevents production embarrassments.
If no
Skip — engineers can validate in staging until non-engineers start authoring templates.
Notifications
Are there urgent notifications that must bypass quiet hours (security alerts, outages)?
If yes
Add a priority flag on notifications and skip DND for priority=urgent. Document this behavior so users expect it.
If no
Quiet hours apply uniformly — simpler and avoids abuse of the override.
Roles & Permissions
Do users need different levels of access in different parts of the product?
If yes
Move beyond simple roles — at minimum, adopt RBAC.
If no
A two-value role enum on the user table is plenty.
Roles & Permissions
Do users share individual items (documents, projects) with specific other users?
If yes
You need per-resource scope. Plan for ABAC or ReBAC now, not later.
If no
Workspace-level scope is usually sufficient.
Roles & Permissions
Are enterprise customers asking to configure roles themselves?
If yes
Expose a role editor on the built-in permission primitives; price it.
If no
Ship a fixed role set and iterate based on feedback.
Roles & Permissions
Do you need per-field permission granularity?
If yes
Move to ABAC or a policy engine (OpenFGA, Cerbos) — field-level rules are unmaintainable in RBAC.
If no
Row/resource-level checks are enough; keep the model coarse.
Roles & Permissions
Do permissions need to inherit via hierarchical groups (folder → subfolder, org → team)?
If yes
ReBAC is the natural fit — Zanzibar-style graph traversal handles inheritance cleanly.
If no
Flat role-to-resource assignments are simpler and easier to debug.
Roles & Permissions
Is deny-by-default the required posture?
If yes
Default every permission check to false; require an explicit grant. Standard for compliance-regulated products.
If no
Allow-by-default with blocklist rules is risky — only acceptable for internal tools.
Roles & Permissions
Must users delegate access (X grants Y access to Z) without an admin?
If yes
Per-resource scope is required. Build a share action with grantor tracking in the audit log.
If no
Admin-mediated grants keep the authorization surface auditable and small.
Roles & Permissions
Do you need policy-as-code (OPA, Cedar) managed alongside application code?
If yes
Adopt a policy engine — policies get versioned, reviewed, and tested like any source file.
If no
Keep authorization as a central module in app code until policy churn justifies the engine.
Roles & Permissions
Do grants need to expire automatically (temporary access, contractor windows)?
If yes
Add an expires_at on every grant and a scheduled job that revokes on expiry. Critical for least-privilege compliance.
If no
Permanent grants with manual revocation are simpler but audit-unfriendly.
Roles & Permissions
Do you need a break-glass / super-admin role for incident response?
If yes
Define it explicitly, require MFA to assume it, and audit-log every action taken under it. Keep the member list tiny.
If no
Regular admin + vendor support access covers most cases; avoid god-mode accounts.
Roles & Permissions
Are sensitive role grants (e.g. billing-admin) subject to approval workflow?
If yes
Build a request + approve flow with a second approver on the granting side. Common in SOC 2 environments.
If no
Direct admin grants are faster — add audit logging instead.
Roles & Permissions
Do enterprise customers need SCIM-driven group membership from their IdP?
If yes
Map SCIM groups to roles; treat the IdP as source of truth and avoid manual role edits for SCIM-managed users.
If no
In-app role management is simpler for SMB customers.
Roles & Permissions
Do permission changes need a dedicated audit log (separate from general audit log)?
If yes
Emit a specialized authz-change stream — compliance reviewers need to query grants without sifting through all activity.
If no
Fold permission changes into the general audit log; tag them for easy filtering.
Roles & Permissions
Do API keys need permissions separate from the user who minted them?
If yes
Give keys their own scoped permission set (typically a subset of the user's). Prevents accidental privilege inheritance.
If no
Mirror the minting user's permissions — simpler but revoking a user breaks their keys.
Roles & Permissions
Can you push authorization into the database with row-level security?
If yes
Postgres RLS (or Supabase) centralizes enforcement at the data layer — out-of-band queries can't bypass it. Set auth context on every connection.
If no
Central policy module in app code is easier to debug and port across databases.
Roles & Permissions
Are permission checks on your hot path (every list render)?
If yes
Cache lookups with a short TTL (30–60s) plus a revocation list checked per request — pure DB lookups will bottleneck.
If no
Uncached checks are fine; add caching only when profiler data demands it.
Audit Logging
Are you pursuing SOC 2, ISO 27001, or a similar audit?
If yes
Plan for append-only storage with >= 1 year retention, authentication + admin + mutation scopes, and an auditor-facing export.
If no
Start with auth events in an append-only table; expand scope when a customer or incident forces it.
Audit Logging
Do customers need to answer "who did X?" inside your product?
If yes
Build an admin audit log UI — you will be asked for one on every enterprise deal.
If no
Internal-only access is fine until you hear the first request.
Audit Logging
Must logs be tamper-evident (hash chain / signing)?
If yes
Chain each log entry by hashing (prev_hash + payload) or sign with an HSM-backed key — required for SOX/HIPAA trail integrity.
If no
Insert-only DB permissions on an append-only table are sufficient for most internal use.
Audit Logging
Retention: 30d, 1y, or 7y+?
If yes
Long retention (1y+): tier cold logs to S3/Glacier with lifecycle rules. 7y+ is a SOX/healthcare signal — plan storage costs.
If no
30–90 days in a hot store (primary DB or ClickHouse) covers security review timelines for non-regulated apps.
Audit Logging
Should logs include before/after diffs on updates?
If yes
Capture a JSON diff (jsondiffpatch or a custom field-level diff) — essential for customer-facing "who changed this?" questions.
If no
Log action + resource ID only; cheaper but limits forensic value.
Audit Logging
Log reads (access logs) or only writes?
If yes
Sample or scope to sensitive resources only — full read logging often produces 100x the write volume. Required for HIPAA.
If no
Write-only logging is the default — covers the overwhelming majority of compliance and forensics needs.
Audit Logging
Store audit logs separately from operational DB?
If yes
Stream to a dedicated store (ClickHouse, S3, or SIEM) — isolates audit traffic from app queries and allows differing retention/permissions.
If no
An append-only table in the primary DB is simpler and sufficient at early scale.
Audit Logging
Cryptographic signing of entries required?
If yes
Sign each entry with an HSM-backed key (AWS KMS) — provides non-repudiation beyond hash chaining.
If no
Hash-chain or insert-only permissions are enough until an auditor asks.
Audit Logging
Exportable as SIEM-compatible (CEF, JSON)?
If yes
Offer structured JSON export and optionally CEF/LEEF for enterprise SIEMs (Splunk, QRadar) — usually gated behind a plan.
If no
A simple CSV export covers most self-serve customers.
Audit Logging
Real-time alerts on specific events?
If yes
Route high-signal events (privilege escalation, mass delete) through a streaming pipeline (Kinesis/Kafka) into alerting — PagerDuty or customer Slack.
If no
Batch nightly review is enough for low-stakes environments.
Audit Logging
Distinguish system actions from user actions?
If yes
Model actor as a typed union (user | system | api_key | admin) — required for any meaningful forensic query.
If no
A single actor_id field works short-term but becomes ambiguous fast — avoid.
Audit Logging
Log IP and user-agent on every action?
If yes
Capture IP + user-agent + geo on every event — standard for security review and fraud investigations.
If no
Auth events only is the bare minimum; expect to backfill later.
Audit Logging
Retain deleted resource IDs in logs indefinitely?
If yes
Keep resource IDs forever — critical for "what happened to record X?" questions after deletion.
If no
Honor GDPR right-to-erasure by tombstoning PII but preserving action records with hashed IDs.
Audit Logging
Redact/tokenize PII in log bodies?
If yes
Run an allowlist + regex redaction pass at the producer before write — tokens, emails, card numbers never land in the log store.
If no
Acceptable only if logs never leave your trust boundary — avoid.
Audit Logging
Log admin impersonation with both identities?
If yes
Record both real_actor and impersonated_user on every event during an impersonation session — required for SOC 2 and customer trust.
If no
Single-actor logs make it impossible to tell who really acted — always log both.
Audit Logging
Is write-once storage (S3 Object Lock) a compliance need?
If yes
Stream logs to S3 with Object Lock compliance mode — cheapest credible WORM store. Neither you nor an attacker can rewrite.
If no
Insert-only DB table is enough until an auditor requires immutable storage.
Transactional Email
Will you ever send marketing email (newsletters, promotions) from the same brand?
If yes
Plan separate transactional and marketing streams from the start.
If no
A single stream is simpler; split later if you add marketing email.
Transactional Email
Do you expect to send >100k emails/month in year one?
If yes
Evaluate SES or Postmark pricing carefully; negotiate volume discounts.
If no
Pick the best developer experience (Resend / Postmark) — the price delta is rounding at low volume.
Transactional Email
Should you use a managed provider (SendGrid, Postmark, SES) or self-host?
If yes
Use a managed provider — Postmark for deliverability, Resend for DX, SES for cost at volume. Self-hosting is never worth it for transactional.
If no
Only self-host for regulated environments with egress constraints; expect months of reputation work.
Transactional Email
Is a dedicated IP justified for your volume?
If yes
Above ~100k emails/month, request a dedicated IP and budget a 2–4 week warm-up. Below that, shared pools from Postmark/SendGrid are cleaner.
If no
Stay on the shared pool — reputation is managed for you.
Transactional Email
Should mail send from an isolated subdomain (mail.yourdomain.com)?
If yes
Standard practice — protects root-domain reputation from email mistakes and makes DNS records easier to manage.
If no
Only sending from root if you have no other choice; keep SPF/DKIM alignment tight.
Transactional Email
Is DMARC enforcement (p=reject or p=quarantine) required?
If yes
Start with p=none for reporting, then ramp to quarantine and reject once SPF+DKIM alignment is verified across all senders.
If no
Inbox providers increasingly require DMARC — plan to enforce within 6 months anyway.
Transactional Email
Do user replies to transactional email need to drive app actions (reply-to-comment)?
If yes
Use a provider with inbound reply parsing (Postmark, SendGrid Inbound Parse) and a dedicated Reply-To subdomain with MX records.
If no
Set Reply-To to a monitored support inbox or no-reply address.
Transactional Email
Does marketing/CX need to edit templates without a code deploy?
If yes
Use provider-hosted templates (SendGrid Dynamic Templates, Postmark) or a notification platform (Knock, Courier). Keep security emails in code.
If no
Code-owned templates (React Email, MJML) are reviewable and version-controlled.
Transactional Email
Do templates need per-recipient personalization beyond name / link?
If yes
Use a templating engine with merge fields (Handlebars, Liquid). Provider templates handle this well; React Email makes it trivial in code.
If no
Static templates with a few variables are fine — don't over-engineer.
Transactional Email
Do you need template versioning with rollback?
If yes
Code templates get this from git for free. For provider templates, pick one with built-in versioning (Postmark) or snapshot before edits.
If no
Direct edits are fine for low-stakes messages.
Transactional Email
Do you need to send localized email content per recipient?
If yes
Either one template per locale (simple, duplicated) or a single template with i18n key lookups. Store recipient locale on the user record.
If no
English-only ships faster; add locales when revenue justifies it.
Transactional Email
Do you need open and click tracking for product email?
If yes
All major providers offer it as a toggle. Useful for onboarding email analytics — but disclose tracking in your privacy policy.
If no
Disable trackers on security-sensitive email (password resets) regardless — tracking pixels in those emails look phishy.
Transactional Email
Are bounce and complaint webhooks processed to suppress bad addresses?
If yes
Non-negotiable at any real volume. Subscribe to provider webhooks and maintain a suppression table checked before every send.
If no
You will tank your sender reputation within weeks — this is not optional.
Transactional Email
Do you need to schedule sends for a future time?
If yes
Most managed providers support scheduled sends natively; otherwise enqueue to a delayed job queue (BullMQ, SQS with delay).
If no
Send immediately from the triggering event — simpler.
Transactional Email
Do you send high-fan-out batches (announcement to all users at once)?
If yes
Use the provider's batch send API (SendGrid v3, Postmark batch). Chunk to stay under per-call limits and spread over minutes to avoid throttling.
If no
One-at-a-time calls via your background queue are simpler.
Transactional Email
Can end-users (white-label customers) customize email content?
If yes
Sandbox the template language (no arbitrary code), validate on save, and preview before activating. Use a notification platform if this is core.
If no
Keep templates locked down — far fewer support tickets.
Transactional Email
Do you need an internal preview / test-send surface for QA?
If yes
Build an admin route that lists all templates with sample data. Pair with Mailpit/Mailhog in dev to catch rendering bugs before prod.
If no
You'll hear about broken templates from customers — not recommended.
Transactional Email
Do you need a single unsubscribe list shared across product surfaces?
If yes
Centralize in your user record or a notification platform — users unsubscribing from any email should stop all non-critical mail.
If no
Per-stream unsubscribes create support tickets; avoid if at all possible.
Onboarding & Activation
Do you know what the "aha moment" / activation event is for your product?
If yes
Design onboarding backwards from that event. Every step should reduce friction to it.
If no
Fix this before investing in onboarding UI. Instrument product events and find activation empirically.
Onboarding & Activation
Is the first use of your product collaborative (requires inviting a teammate)?
If yes
Surface the invite action prominently in empty states or checklist; single-user usage is often not the activated state.
If no
Optimize for a single-user first success.
Onboarding & Activation
Is your product self-serve, or sales-led / waitlisted?
If yes
Optimize every step for a frictionless signup: single-field email, magic link, and empty-state-driven first action.
If no
Replace signup with a waitlist form + personal outreach; add a wizard (domain verification, SSO) post-sales.
Onboarding & Activation
Is email verification strictly required before first use?
If yes
Send magic link or OTP, but let the user explore read-only state while waiting. Blocking on verification is a major conversion leak.
If no
Skip upfront verification — prompt later when the user takes an action that actually needs a verified email.
Onboarding & Activation
Would a 1-2 question questionnaire meaningfully personalize the first experience?
If yes
Ask role/use-case upfront and route to a tailored template or empty state. Cap at 2 questions — each additional one costs conversion.
If no
Skip the questionnaire; ship the same empty state to everyone and let them self-select via templates.
Onboarding & Activation
Does your product suffer from the blank-page problem (hard to see value empty)?
If yes
Pre-populate a labeled, deletable sample workspace. Essential for analytics, dashboards, and issue trackers.
If no
An empty-state prompt to "Create your first X" is cleaner and avoids clutter.
Onboarding & Activation
Is team invites in the first session a leading indicator of activation?
If yes
Surface the invite step inside the checklist during onboarding — not after. A team workspace that stays single-user usually churns.
If no
Move invites out of onboarding — prompt only when the user takes a collaborative action.
Onboarding & Activation
Does the product only deliver value once external data is connected (integrations, imports)?
If yes
Make the connect-data step the checklist centerpiece. Offer sample data as a fallback so users can explore before committing.
If no
Skip data connection in onboarding — offer it contextually when the user takes an action that needs it.
Onboarding & Activation
Is your product complex enough that new users will miss key capabilities without guidance?
If yes
Add a short guided tour (under 5 steps) with a clear skip control. Never block the UI behind the tour.
If no
Skip the tour — empty-state prompts and in-app help cover it without the friction.
Onboarding & Activation
Does your product surface more features as users mature (advanced settings, integrations)?
If yes
Progressively disclose — hide admin/API/settings until they are needed. Surface them via contextual prompts when the user is ready.
If no
Show the full surface from day one; simpler mental model.
Onboarding & Activation
Do different user roles (admin, member, viewer) need materially different first experiences?
If yes
Branch onboarding on role — admins get setup checklist (billing, SSO, invites); members land directly in the workspace.
If no
One flow for all users is simpler and easier to iterate on.
Onboarding & Activation
Can your empty states double as the onboarding surface?
If yes
Invest in empty-state-driven onboarding first. Every empty screen should show the next primary action, not marketing copy.
If no
Supplement with a checklist — but fix the empty states first; they will carry users further than any tour.
Onboarding & Activation
Have you defined and instrumented a product activation metric (time-to-value)?
If yes
Track it in your analytics and optimize onboarding against it. Every step should either reduce TTV or get cut.
If no
Instrument this before building onboarding UI — without a metric you are guessing.
Onboarding & Activation
Do a meaningful fraction of signups drop off before activation?
If yes
Enable behavior-triggered activation emails. A nudge at day 1 and day 3 recovers 5–15% of dropped signups.
If no
Skip — nudges on already-activated users feel spammy.
Onboarding & Activation
Do you have the analytics maturity and signup volume to A/B test onboarding variants?
If yes
Use an experimentation framework (Statsig, LaunchDarkly, GrowthBook) and test one variable at a time.
If no
Iterate with qualitative feedback first — A/B tests need thousands of signups per week to reach significance.
Onboarding & Activation
Does your product require payment or a card before the user sees value?
If yes
Only if you can justify it (enterprise, physical goods). For SaaS, defer card collection until after the user reaches their aha moment.
If no
Keep payment setup out of onboarding — gate it on usage or trial expiry.
Onboarding & Activation
Do enterprise customers need to complete setup steps (domain verification, SSO, SCIM) before go-live?
If yes
Build a separate admin wizard post-signup for these. Keep end-user onboarding lightweight; admin work should not block the team.
If no
Skip the enterprise wizard entirely until you have paying enterprise customers requesting it.
Preset
Authentication Methods*
Access Control*
Multi-factor Authentication
Tradeoffs
Each provider requires an OAuth app registration and key rotation policy
Requires IdP partnership and XML-based protocol handling; significant integration work
Permission checks must be applied consistently across every data access path
Search Approach*
Search Scope*
Tradeoffs
Requires FTS index maintenance; adds write-time overhead
Embedding generation adds latency and API cost per indexed document
Results must be unified and ranked across disparate data models
Delivery Method*
User Control
Tradeoffs
Requires persistent connection infrastructure (e.g. Redis pub/sub, WebSocket server)
Higher server request volume; notifications may lag by poll interval
Requires APNs/FCM credentials and certificate management
Significantly more complex preference storage and UI
Authorization Model*
Permission Scope*
Custom Role Management
Tradeoffs
Fast to build but every 'special case' access rule becomes bespoke code that's hard to audit
Requires a policy engine and relationship store kept in sync with primary data
Every list/read query must filter by ACL — expect query-plan work and caching investment
Support load increases substantially — each customer now has a unique permission configuration
What to Log*
Storage Backend*
User-facing Surface
Tradeoffs
Read amplification — every authenticated read produces a log write
Two storage systems to operate and keep in sync; queries may need to federate
Tamper-evidence relies on DB role permissions — insufficient for some compliance regimes
Delivery Provider*
Deliverability Setup*
Templating Approach*
Tradeoffs
Vendor cost scales with volume; deliverability expertise comes included
Low per-email cost but you own deliverability operations (reputation, bounces, suppression)
Two sending configurations and domains to maintain — worth it for deliverability isolation
Onboarding Format*
Personalization Signals
Activation Support
Tradeoffs
Controls first-experience but introduces sign-up drop-off proportional to wizard length
Requires event tracking + scheduled jobs + segmentation infrastructure
Staffing cost scales with signup volume — not viable for self-serve products below a certain ACV