Choose a stack that fits the product
Evaluate rendering, data, interaction, deployment, and maintenance before choosing a framework.
Why this matters
You are choosing tools for the crew scheduler — or deciding whether to keep what exists. Pick tools that make the product's constraints easier to meet. On an existing product, the cost of changing a working stack is part of the decision.
What to understand
Split the work: what the browser shows, and what the server checks and saves. Tomorrow's assignments must load on a phone with poor signal, and only the foreman may reassign. Ask your agent: "Which of these needs the server to check or save, and what can the browser do alone?"
Rendering and interactivity are separate decisions. A page rendered on the server can become interactive after it loads, and a browser app can still use a server for every protected operation. This team's examples use React and Next.js — examples of a working approach, not a standing recommendation.
Watch for
- Treating the team's example stack as the recommendation for every project.
- Assuming Vite rules out discoverable content — it supports SSR.
- "It deploys" meaning a starter page loads, not the intended runtime, identity path, and configuration together.
- Committing to a migration before a narrow spike on the uncertain integration.
- Ignoring the saved-copy model, runtime limits, deep-link hosting, and who the client can operate.
Strong default
Check the framework's runtime and saved-copy model against the host you need. Budget for routing, loading, saved-copy ownership, identity checks, and deep-link behavior. Spike the risky integration before committing.
When this doesn't apply
An existing team ecosystem can be the strongest choice when its components, integrations, and maintenance knowledge already fit — even if a newer framework looks cleaner. A content-focused generator fits a mostly static site, but only after you identify what must rebuild and which features still need a service.
In practice
| Product need | Architectural question |
|---|---|
| Public articles or product pages | Should useful HTML arrive before JavaScript? How is content refreshed? |
| Authenticated workspace | Where are who you are and what you are allowed to do (authentication and authorization), and one client's data never leaking into another's (tenant isolation), enforced? |
| Interactive editor | Which work belongs in the browser? What must be saved or synchronized? |
| Offline use | What can be kept as saved copies (cache), edited, and reconciled safely? |
| Background processing | How does the UI track work that finishes after the reply (background work)? |
| Client-owned deployment | Which runtimes and services can the client operate? |
- A full-stack framework can coordinate routing, rendering, data loading, and deployment conventions. Check its runtime and saved-copy model against the host you need.
- A client-focused app with a separate API can fit a tool-like experience or an existing backend. Budget for routing, loading, saved-copy ownership, identity checks, and deep-link hosting behavior.
- A content-focused generator can simplify a mostly static site. Identify what must rebuild and which features still need a service.
- An existing team ecosystem can be the strongest choice when its components, integrations, and maintenance knowledge already fit.
Map the dependency categories before naming products. A complete stack answers each of these; an unanswered one is the actual risk:
| Category | Question it answers | Examples of pieces |
|---|---|---|
| Runtime | Where does the code execute? | Node, Bun, edge runtime |
| Framework | Who owns routing and rendering? | Full-stack framework, SPA plus API, static generator |
| API layer | How do browser and server exchange data? | REST endpoints, type-safe RPC, server functions |
| Data access | Where does data live and how is it queried? | Database, ORM or query layer, migrations |
| Auth | Who are you, and what may you do? | Identity provider, sessions, server-side checks |
| Hosting | How does it build, deploy, and preview? | Host, preview environments, env config |
Scaffolders like better-t-stack turn a chosen combination into a working starter — check its current compatibility rules before treating any pairing as safe. Menus change; the categories don't.
For current implementation details, consult the official Next.js documentation, Nuxt documentation, or Vite documentation.
Choose: retain the current Vue application and API.
Because: the team owns reusable controls and the hosting path works.
Cost accepted: public content needs a separate rendering decision.
Verify: preview a deep link and complete one authenticated write.
Revisit if: the public content becomes the dominant product surface.Verify
Preview a deep link and complete one authenticated write on the intended runtime. Revisit if the dominant surface changes — for example, public content overtaking the workspace.
Related skills
Use $stack to compare constraints and $setup to turn the decision into a runnable foundation. Continue with project setup.
Last updated on