Technologies

Every dependency in the free Hype Stack starter earns its place. Here is what is inside, how the repository is laid out, and why each piece is there.

Runtime zones

Build and tooling (Vite, Nx, Prisma CLI, oxlint) run on Node at the workspace root. They are not part of the production request path.

Repository layout

The project is a pnpm monorepo with Nx orchestrating tasks:

apps/
  backend/    # Hono API server, Prisma schema, docker-compose.yml
  frontend/   # React SPA (web + Electron)
  admin/      # Operator app, a placeholder home until a starter fills it
  mobile/     # Expo app (expo-router, NativeWind)
  extension/  # Browser extension (Vite, Tailwind)
packages/     # Shared code (enums, types, configs)
nx.json
pnpm-workspace.yaml
stack.json    # apps, paths, installed packs, deploy records

Installing a starter pack fills apps/admin with its login and screens, and adds auth, organizations, permissions, and admin routes under apps/backend. Feature packs (billing, teams, notifications) add more files into those apps. Every app deploys independently and talks to the API over HTTP, so restarting the API does not rebuild the UI.

Free template vs pack-added

Backend

Two query tools is deliberate. Prisma owns the schema and migrations, Kysely owns the hard queries, and each is used for what it is good at.

Frontend

Mobile

Local device testing uses Expo Go from sign.expo.dev. See Mobile.

Extension

Both apps talk to the same Hono API through HyperFetch, and both are themed by the CLI's theme picker alongside the frontend and admin.

Tooling

How types travel

There is no code generation step to remember and no schema language to maintain. A Hono route validated with Zod exposes its input and output types, HyperFetch builds a typed SDK from the Hono app type (registerRoutes return type), and the frontend imports only that SDK. Add an endpoint on the backend and it is typed on the client immediately. Change a response shape and the frontend stops compiling.

Read end-to-end type safety for the full chain, and HTTP for how components call the SDK.

What the free starter already handles

These are wired before you install a single pack:

• Error handling. Typed error classes and one central error middleware that formats responses, logs, and reports to Sentry. Route code throws and moves on.
• Real-time. Websocket listeners and emitters through the same typed SDK, with reconnection handled.
• Caching. Valkey reads and writes that degrade gracefully instead of failing a request.
• Background jobs. A cron scheduler that boots with the API. The job list ships empty; packs append entries through the manifest, and your own jobs go in apps/backend/src/jobs/index.ts.
• Task queue. Slow work (file parsing, model calls, batch sends) runs as tasks on Postgres, with retries and a concurrency cap. It runs inside the API process, and it costs nothing until a pack registers a queue.
• Translations. Paraglide message catalogs in the frontend, admin, mobile, and backend. Add a locale file and every pack string is translatable.
• A dashboard shell. Sidebar navigation, settings screens, and the layout patterns features plug into.
• Local infrastructure. Postgres, Valkey, and RustFS in Docker Compose, plus Prisma migrations against them.
• CI. Lint, typecheck, and test pipelines that understand the monorepo graph.

Paid provider integrations, including WorkOS auth and Stripe billing, are not part of the free starter. They arrive with the packs that need them.

What the template does not ship

These show up in some other SaaS kits. Here is where each one stands in Hype Stack today:

Documenting the boundaries matters so you do not expect dashboard toggles that are not there.