305 lines
15 KiB
Markdown
305 lines
15 KiB
Markdown
# Tech Stack Options
|
||
|
||
Default comparison data for PLAID tech stack questions. Use these as a baseline and adapt recommendations based on the specific product’s needs. The comparison format and pros/cons should be adjusted to reflect how each option fits the founder’s particular product.
|
||
|
||
-----
|
||
|
||
## Frontend Frameworks
|
||
|
||
### Web Apps
|
||
|
||
**Next.js** — React framework with server-side rendering, file-based routing, and excellent deployment options.
|
||
|
||
- ✓ Largest React ecosystem, huge community, extensive documentation
|
||
- ✓ App Router with server components for performance
|
||
- ✓ Excellent integration with Vercel, Convex, Clerk, and most services
|
||
- ✓ Best-supported by AI coding tools (most training data)
|
||
- ✗ Can be complex — many ways to do things (server vs client components)
|
||
- ✗ Opinionated about project structure
|
||
- **Best for:** Most web apps. Default recommendation unless there’s a specific reason not to.
|
||
|
||
**Remix** — Full-stack React framework focused on web standards and progressive enhancement.
|
||
|
||
- ✓ Excellent form handling and data loading patterns
|
||
- ✓ Progressive enhancement — works without JavaScript
|
||
- ✓ Simpler mental model than Next.js (loaders + actions)
|
||
- ✗ Smaller ecosystem than Next.js
|
||
- ✗ Less AI coding tool familiarity
|
||
- **Best for:** Form-heavy apps, content-heavy sites, apps that need to work without JS.
|
||
|
||
**SvelteKit** — Svelte framework with file-based routing and server-side rendering.
|
||
|
||
- ✓ Significantly less boilerplate than React
|
||
- ✓ Excellent performance — smaller bundle sizes
|
||
- ✓ Built-in state management (no Redux/Zustand needed)
|
||
- ✗ Smaller ecosystem and community than React
|
||
- ✗ Fewer component libraries available
|
||
- ✗ Less AI coding tool support
|
||
- **Best for:** Performance-critical apps, developers who prefer less boilerplate.
|
||
|
||
### Mobile Apps
|
||
|
||
**Expo / React Native** — Cross-platform mobile framework with managed workflow.
|
||
|
||
- ✓ Write once, run on iOS and Android
|
||
- ✓ Expo managed workflow eliminates native build complexity
|
||
- ✓ React knowledge transfers directly
|
||
- ✓ Over-the-air updates
|
||
- ✗ Performance can lag behind native for graphics-heavy apps
|
||
- ✗ Some native APIs require ejecting from managed workflow
|
||
- **Best for:** Most mobile apps. Default recommendation for mobile.
|
||
|
||
**Flutter** — Google's cross-platform UI toolkit using Dart.
|
||
|
||
- ✓ Excellent performance — compiles to native
|
||
- ✓ Beautiful, customizable UI components
|
||
- ✓ Single codebase for iOS, Android, web, desktop
|
||
- ✗ Dart is a separate language to learn
|
||
- ✗ Less ecosystem integration with JS/TS backends
|
||
- ✗ Less AI coding tool support than React Native
|
||
- **Best for:** Apps needing pixel-perfect custom UI or very high performance.
|
||
|
||
### Desktop Apps
|
||
|
||
**Electron** — Build cross-platform desktop apps with Chromium and Node.js. Powers VS Code, Slack, Discord, Figma, and Notion.
|
||
|
||
- ✓ Most mature desktop framework — battle-tested at massive scale
|
||
- ✓ Full web technology stack (HTML, CSS, JS/TS) — no new language to learn
|
||
- ✓ Largest ecosystem of plugins, tools, and community resources
|
||
- ✓ Excellent AI coding tool support (most training data)
|
||
- ✗ Heavy memory footprint — each app bundles its own Chromium instance
|
||
- ✗ Large bundle sizes (100MB+ minimum)
|
||
- ✗ Can feel non-native on macOS — requires extra work to match platform conventions
|
||
- **Best for:** Most desktop apps. Default recommendation for desktop. Especially strong when the team already knows web technologies.
|
||
|
||
**Tauri** — Lightweight desktop framework using the OS's native webview and a Rust backend.
|
||
|
||
- ✓ Dramatically smaller bundles than Electron (often 5-10MB vs 100MB+)
|
||
- ✓ Lower memory usage — uses the OS webview instead of bundling Chromium
|
||
- ✓ Rust backend for performance-critical operations and system access
|
||
- ✓ Strong security model — fine-grained permission system for system APIs
|
||
- ✗ Younger ecosystem — fewer community resources and plugins than Electron
|
||
- ✗ Rust knowledge needed for backend plugins and system integrations
|
||
- ✗ OS webview inconsistencies can cause cross-platform rendering differences
|
||
- **Best for:** Desktop apps where bundle size and memory matter, or when deep system integration is needed. Good for developers comfortable with Rust.
|
||
|
||
**Flutter (Desktop)** — The same Flutter framework listed under Mobile, with support for macOS, Windows, and Linux.
|
||
|
||
- ✓ Single codebase across mobile, web, and desktop — true cross-platform
|
||
- ✓ Compiles to native — good performance without a webview
|
||
- ✓ Consistent UI across all platforms
|
||
- ✗ Desktop support is less mature than mobile — some platform APIs are missing
|
||
- ✗ Dart ecosystem is smaller than JS/TS for desktop-specific needs
|
||
- ✗ Apps don't follow native platform UI conventions by default
|
||
- **Best for:** Projects that need a single codebase across mobile AND desktop. Not recommended for desktop-only apps — Electron or Tauri are better choices there.
|
||
|
||
-----
|
||
|
||
## Backend
|
||
|
||
**Convex** — Reactive backend-as-a-service with built-in database, real-time sync, and TypeScript-native functions.
|
||
|
||
- ✓ Real-time data sync out of the box — no WebSocket setup
|
||
- ✓ Zero backend boilerplate — define functions, they just work
|
||
- ✓ Built-in auth, file storage, scheduling, search
|
||
- ✓ TypeScript end-to-end with full type safety
|
||
- ✓ Excellent DX for solo developers — fast iteration
|
||
- ✓ ACID transactions on the database
|
||
- ✗ Newer ecosystem — fewer community resources
|
||
- ✗ Vendor dependency — data lives on Convex Cloud
|
||
- ✗ Different mental model from traditional REST APIs
|
||
- **Best for:** Most products, especially real-time apps, solo developers, MVPs. Default recommendation.
|
||
|
||
**Supabase** — Open-source Firebase alternative built on PostgreSQL.
|
||
|
||
- ✓ PostgreSQL under the hood — full SQL power, relational data
|
||
- ✓ Real-time subscriptions, auth, storage, edge functions
|
||
- ✓ Open source — can self-host if needed
|
||
- ✓ Large and growing community
|
||
- ✗ More setup than Convex — manual schema migrations
|
||
- ✗ Real-time requires explicit subscription setup
|
||
- ✗ Edge functions are less integrated than Convex functions
|
||
- **Best for:** Products with complex relational data, teams that want SQL and open-source.
|
||
|
||
**Node.js + Express + PostgreSQL** — Traditional server setup with full control.
|
||
|
||
- ✓ Maximum flexibility — build exactly what you need
|
||
- ✓ Largest ecosystem of packages and middleware
|
||
- ✓ Full control over infrastructure and hosting
|
||
- ✗ Significant boilerplate — auth, validation, error handling, CORS, etc.
|
||
- ✗ You manage everything: database migrations, deployment, scaling
|
||
- ✗ Slower to iterate as a solo developer
|
||
- **Best for:** Experienced backend developers who want full control, or products with unusual requirements.
|
||
|
||
-----
|
||
|
||
## Database
|
||
|
||
**Convex Database** — Document-relational database built into the Convex platform.
|
||
|
||
- ✓ Automatic reactive queries — UI updates when data changes
|
||
- ✓ ACID transactions with optimistic concurrency
|
||
- ✓ Automatic indexing — define indexes in schema, they just work
|
||
- ✓ TypeScript schema validation built-in
|
||
- ✗ Only available with Convex backend
|
||
- ✗ Document-oriented — different from SQL thinking
|
||
- **Best for:** Any product using Convex backend. Use this — it’s part of the package.
|
||
|
||
**PostgreSQL** — The gold-standard open-source relational database.
|
||
|
||
- ✓ Rock-solid reliability and ACID compliance
|
||
- ✓ Full SQL power — complex queries, joins, aggregations
|
||
- ✓ Excellent for relational data with complex relationships
|
||
- ✓ Massive ecosystem of tools and extensions
|
||
- ✗ Requires migrations for schema changes
|
||
- ✗ No built-in real-time — need separate pub/sub
|
||
- **Best for:** Products with complex relational data. Pairs with Supabase or traditional backends.
|
||
|
||
**Supabase Database (PostgreSQL)** — Managed PostgreSQL via the Supabase platform with a dashboard, auto-generated APIs, and real-time subscriptions.
|
||
|
||
- ✓ Full PostgreSQL — complex queries, joins, extensions, relational power
|
||
- ✓ Auto-generated REST and GraphQL APIs from your schema
|
||
- ✓ Real-time subscriptions built in
|
||
- ✓ Row Level Security for fine-grained access control
|
||
- ✓ Dashboard with table editor — visual schema management
|
||
- ✗ Only makes sense with Supabase backend
|
||
- ✗ Migrations still needed for production schema changes
|
||
- **Best for:** Supabase backends — use this, it’s part of the package. Excellent for relational data.
|
||
|
||
**None (local-only / no database)** — The app stores data on-device only (AsyncStorage, SQLite, UserDefaults, local files).
|
||
|
||
- ✓ Zero infrastructure — no backend costs, no latency
|
||
- ✓ Works offline by default
|
||
- ✓ Simpler architecture — no sync, no API calls
|
||
- ✗ Data is lost if the user deletes the app (unless backed up)
|
||
- ✗ No cross-device sync
|
||
- ✗ No server-side logic or shared data
|
||
- **Best for:** Mobile apps that are primarily tools (calculators, trackers, utilities), offline-first apps, or MVPs that don’t need shared data. Consider adding a backend later if the product grows.
|
||
|
||
-----
|
||
|
||
## Auth Providers
|
||
|
||
**Convex Auth** — Native auth built into the Convex platform.
|
||
|
||
- ✓ Zero-config integration with Convex backend
|
||
- ✓ Supports email/password, OAuth providers, magic links
|
||
- ✓ User data lives in Convex — no external service calls
|
||
- ✗ Only works with Convex backend
|
||
- ✗ Fewer pre-built UI components than Clerk
|
||
- **Best for:** Convex backends where simplicity is priority.
|
||
|
||
**Clerk** — Drop-in auth with pre-built UI components.
|
||
|
||
- ✓ Beautiful, pre-built sign-in/sign-up components
|
||
- ✓ Social login, MFA, organization management out of the box
|
||
- ✓ Excellent React/Next.js integration
|
||
- ✓ Generous free tier (10,000 MAUs)
|
||
- ✗ External service dependency
|
||
- ✗ Monthly cost at scale
|
||
- **Best for:** Products that want polished auth UI fast. Works with any backend.
|
||
|
||
**Auth.js (NextAuth)** — Open-source auth for Next.js.
|
||
|
||
- ✓ Open source — no vendor dependency
|
||
- ✓ Supports many OAuth providers
|
||
- ✓ Database adapters for most databases
|
||
- ✗ More setup and configuration than Clerk
|
||
- ✗ Less polished UI — you build your own forms
|
||
- ✗ Session management can be tricky
|
||
- **Best for:** Developers who want open-source auth with full control.
|
||
|
||
**Supabase Auth** — Auth built into the Supabase platform.
|
||
|
||
- ✓ Integrated with Supabase — Row Level Security uses auth
|
||
- ✓ Email/password, magic links, OAuth providers
|
||
- ✓ Free with Supabase
|
||
- ✗ Only makes sense with Supabase backend
|
||
- ✗ Less polished than Clerk’s UI components
|
||
- **Best for:** Supabase backends — use this, it’s part of the package.
|
||
|
||
**None (no auth needed)** — The app doesn’t require user accounts or sign-in.
|
||
|
||
- ✓ Simpler UX — no sign-up friction, instant access
|
||
- ✓ Less infrastructure to manage
|
||
- ✓ Better for tools, utilities, and single-player experiences
|
||
- ✗ No personalization or saved preferences across devices
|
||
- ✗ Can’t gate features behind subscription tiers (without device-level checks)
|
||
- **Best for:** Mobile utility apps, offline tools, calculators, single-player experiences, or MVPs testing core value before adding accounts. Can always add auth later.
|
||
|
||
-----
|
||
|
||
## Payment Providers
|
||
|
||
### Web / SaaS Payments
|
||
|
||
**Polar** — Developer-first payment platform for SaaS and digital products.
|
||
|
||
- ✓ Built specifically for developers and SaaS products
|
||
- ✓ Handles subscriptions, one-time payments, and licensing
|
||
- ✓ Excellent API and webhook support
|
||
- ✓ Generous free tier — no monthly fee, only transaction fees
|
||
- ✓ Built-in customer portal
|
||
- ✗ Newer platform — smaller community than Stripe
|
||
- ✗ Less suitable for physical goods or complex billing
|
||
- **Best for:** SaaS products, digital products, developer tools. Default recommendation for web.
|
||
|
||
**Stripe** — The most flexible and widely-used payment platform.
|
||
|
||
- ✓ Supports virtually any payment model
|
||
- ✓ Largest ecosystem — extensive documentation, libraries, integrations
|
||
- ✓ Stripe Checkout for quick integration
|
||
- ✓ Billing portal, invoicing, subscription management
|
||
- ✗ Complex — many concepts to learn (Products, Prices, Subscriptions, etc.)
|
||
- ✗ You handle tax calculation separately (or use Stripe Tax)
|
||
- ✗ More setup than Polar for simple SaaS billing
|
||
- **Best for:** Products with complex billing needs, marketplaces, or if you need maximum flexibility.
|
||
|
||
**Lemon Squeezy** — Merchant of record for digital products.
|
||
|
||
- ✓ Handles global tax compliance — they’re the merchant of record
|
||
- ✓ Simple setup for subscriptions and one-time payments
|
||
- ✓ Built-in affiliate program
|
||
- ✓ No need to register for tax in different jurisdictions
|
||
- ✗ Higher fees than Stripe (they handle tax liability)
|
||
- ✗ Less flexible than Stripe for complex billing
|
||
- ✗ Smaller ecosystem
|
||
- **Best for:** Solo founders selling internationally who don’t want to deal with tax compliance.
|
||
|
||
### Mobile In-App Payments
|
||
|
||
For mobile apps distributed through the App Store or Google Play, in-app purchases (IAP) are often required by platform policies. These tools manage subscriptions and purchases through the native store billing systems.
|
||
|
||
**RevenueCat** — Cross-platform in-app subscription management.
|
||
|
||
- ✓ Abstracts Apple and Google billing APIs into one SDK
|
||
- ✓ Handles receipt validation, entitlements, and subscription status server-side
|
||
- ✓ Excellent dashboard with analytics, cohorts, and churn tracking
|
||
- ✓ Generous free tier — free up to $2,500/month in tracked revenue
|
||
- ✓ Works with React Native/Expo, Flutter, Swift, Kotlin
|
||
- ✓ Webhook support for backend integration
|
||
- ✗ Another dependency and point of failure in the payment flow
|
||
- ✗ Paid tiers add up as revenue grows (1% of tracked revenue after free tier)
|
||
- **Best for:** Any mobile app with subscriptions or one-time IAP. Default recommendation for mobile payments.
|
||
|
||
**Superwall** — Paywall A/B testing and management platform.
|
||
|
||
- ✓ Build and deploy paywalls remotely — no app update needed to change pricing UI
|
||
- ✓ Built-in A/B testing for paywall designs, pricing, and placement
|
||
- ✓ Pre-built paywall templates that convert well
|
||
- ✓ Analytics on conversion, trial starts, and revenue per paywall
|
||
- ✓ Works with RevenueCat or handles purchases directly via StoreKit/Billing
|
||
- ✗ Focused on paywall presentation — not a full subscription backend (pair with RevenueCat for that)
|
||
- ✗ Adds SDK overhead to your app
|
||
- ✗ Free tier is limited — paid plans required for A/B testing
|
||
- **Best for:** Mobile apps that want to optimize subscription conversion through paywall experimentation. Best paired with RevenueCat for the full billing stack.
|
||
|
||
**None (no payments needed)** — The app is free with no monetization, or monetization will be added later.
|
||
|
||
- ✓ Ship faster — no payment integration complexity
|
||
- ✓ No App Store commission considerations
|
||
- ✓ Focus entirely on core product value
|
||
- ✗ No revenue from day one
|
||
- ✗ Adding payments later requires an app update and review
|
||
- **Best for:** Free utility apps, apps exploring product-market fit before monetizing, or apps monetized through other channels (ads, enterprise contracts, etc.).
|