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

E-commerce Storefront9 features
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

fromE-commerce Storefront
File Storagemedium

Storage Backend*

Files stored on the server filesystem
AWS S3, Cloudflare R2, MinIO, etc.
Object storage + edge CDN for global delivery

File Processing

Scan uploads for malware before storing
Auto-generate thumbnails on upload
Verify file type matches declared MIME type

Tradeoffs

ScalabilityLocal disk selected

Not horizontally scalable; lost on server replacement without backup

CostCDN-backed storage selected

Higher monthly cost; requires cache invalidation strategy

LatencyVirus scanning selected

Upload latency increases; requires AV service integration

fromE-commerce Storefront
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

fromE-commerce Storefront
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

fromE-commerce Storefront
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

fromE-commerce Storefront
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

fromE-commerce Storefront
Searchmedium

Search Approach*

Structured filters on known fields; no free-text
SQLite FTS5 or Postgres tsvector; keyword matching
Embedding-based similarity search

Search Scope*

Search within one list or dataset
Search across multiple resource types simultaneously

Tradeoffs

ComplexityFull-text search selected

Requires FTS index maintenance; adds write-time overhead

CostSemantic search selected

Embedding generation adds latency and API cost per indexed document

ComplexityGlobal search selected

Results must be unified and ranked across disparate data models

fromE-commerce Storefront
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

fromE-commerce Storefront
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

fromE-commerce Storefront

Summary

9 of 9 composed features enabled

Pulled from 1 source spec

Effort Estimate

10+ weeks

5+ engineers