App Stack Decision Ladder
Use this when you have an app idea and need to pick the smallest stack that can ship it without hiding platform work.
The core question is not “can AI write this stack?” The useful question is whether the stack gives you the right platform APIs, release path, quality gates, operational simplicity, and escape hatches for the product.
Default Ladder
| First true condition | Default stack family | Why |
|---|---|---|
| It is docs, reports, content, or a mostly static prototype | Static Astro or static web | Cheapest build and hosting path |
| It is a workflow app that can live in browser APIs | Web/PWA | Broad reach, low distribution friction, installable/offline options |
| It needs one mobile OS deeply | Native mobile | Best permissions, native APIs, store-policy fit, performance |
| It needs Android and iOS at launch with standard native APIs | Expo/React Native | Strong solo-dev workflow and managed build/update path |
| It needs one branded UI across mobile, desktop, and web | Flutter | One rendering model and broad platform targets |
| It is a local-first desktop tool | Tauri 2 or Electron | Pick by security/footprint versus Chromium/Node consistency |
| It is automation, developer workflow, or batch processing | CLI | Smallest product surface and easiest distribution for technical users |
| It requires shared state, auth, payments, queues, or integrations | Backend/API plus a thin UI | Server exists for product requirements, not by habit |
| AI tools, local models, MCP, sandboxing, or workspace isolation are core | AI-native app stack | Tool execution and trust boundaries become first-class architecture |
Gotcha: Backend-first is often a smell. Add a server when the product needs a server-side trust boundary or shared state. Do not add one because every tutorial starts with one.
What To Read First
- Ladder Map - visual flow from app idea to stack family
- Decision Model - the constraints that matter before framework taste
- Choose a Stack - ten-question intake checklist
- Default Picks - lab defaults and avoid triggers
- Wrong Stack Smells - symptoms that the choice is fighting the product
Stack Family Guides
- Choose Mobile Stack - native Android/iOS vs Expo, Flutter, Kotlin Multiplatform, PWA
- Choose Desktop Stack - Tauri, Electron, Windows App SDK, Wails, CLI
- Choose Web or PWA - static, PWA, SSR/API runtime, Cloudflare boundaries
- Choose Backend/API Stack - when a server is necessary
- Choose CLI Stack - when a CLI is the product
- Choose AI-Native Stack - MCP, local models, sandboxing, tools, audit logs
Worked Examples
- Android SMS Finance App - why Android native wins for SMS permissions and privacy-first local data
- Markdown Task Planner - why Electron can beat Tauri for Chromium-consistent UX
- Local AI Assistant - AI-native boundaries from Jan, AnythingLLM, and MyLocalGPT research
- Lab Content Surface - Astro/static-first surface selection
Universal Quality Gates
Every stack choice needs proof before implementation starts:
- You can name the app shape and the platform APIs it needs.
- You can name the distribution path and policy/signing work.
- You can run or at least identify create, dev, test, build, package, and release commands.
- You can identify the smallest maintainable starter shape.
- You can name the first realistic device, browser, emulator, or runtime smoke test.
- You know what would make this stack the wrong choice.
Follow-Up Stack Packs
This topic is the ladder, not the encyclopedia. Deeper operational details belong in stack capability packs. Start with Follow-Up Stack Packs.