Free, and public on GitHub

Three apps.
One codebase.

A frontend, a backend, and an admin panel that already know about each other. Types run from the database to the button, so a mistake is a compile error instead of an incident.

See template's code Installation guide

Your applocalhost:3000/settings/members

The starter's members table, the customer-facing app

Admin panellocalhost:3001

The admin dashboard that ships alongside it

APIlivelocalhost:4000

GET/organizations2006ms

POST/invitations20012ms

GET/settings/members2008ms

three apps, one set of types

You get 3 applications.

A frontend, a backend, and an admin panel. Your ai agent knows all three, so one sentence lands in all three.

Hand your agent the MCP server and let it build the whole thing on its own.

01·Your application

Frontend

queued

What your customers see and click.

02·Your functionality

Backend

queued

What runs behind your system logic.

03·Your analytics

Admin panel

queued

What you watch to run the business.

Not a developer? You can still build the whole thing.

The rules keep your agent inside conventions a professional team would recognize. The day you hand this to a real developer, they open a normal repo with types, tests, and lint rules. Nothing to untangle, nothing to rewrite.

Switch anytime

SSR, CSR, or desktop? Choose later.

The choice that stalls every kickoff is reversible here. One codebase carries three build targets, so you decide when you actually know, and change your mind without a rewrite.

Need SEO mid-development?

Google reads every page

Pages render on the server, so crawlers and link previews see real content instead of an empty shell. Flip it on the week SEO starts to matter.

pnpm start:ssr

same routes, same components, same types. switching back is one command too.

my-app.com · html arrives renderedseo ready

liverendered on the server

Already built

Weeks of screens, already in the repo.

Real captures from the SaaS starter: onboarding, members, invitations, and the admin panel behind them. Screens like these are usually the first month of a build.

The starter's onboarding flow, where a new user picks or creates an organization

The members table with roles and row actions

The invite-a-member dialog with a role attached

Organizationlocalhost:3000/settings/organization

Profilelocalhost:3000/settings/profile

Organizationlocalhost:3000/settings/organization

Profilelocalhost:3000/settings/profile

Organizationlocalhost:3000/settings/organization

Profilelocalhost:3000/settings/profile

Organizationlocalhost:3000/settings/organization

Profilelocalhost:3000/settings/profile

The admin panel's dashboard, a separate app with its own login

A single user's detail view in the admin panel

Three apps to start. Add more as you go.

A product, an admin panel, and an API that already know about each other, booted by one command. When you need billing or notifications later, a pack drops the next piece into the same repo.

Installation guide

Frontend

React 19 · TanStack

Backend

Hono · Postgres

Admin

Own login · widgets

The next one

billing · notifications · packs

one Postgres · one set of types

3+ months
onboarding
members
invites
admin
Of screens and plumbing, already built
Onboarding, members, invitations, and the admin panel behind them. The part of a build customers never see.
100%
everything in your repo
no platform, no export
Of the source lands in your repo
No platform, no fees, nothing hosted by us. Walk away any time and keep everything.
3
websitessrdesktop
one codebase
Build targets from one codebase
Website, server-rendered app, or desktop app via Electron. Same code, your pick.

What you get

Four claims. Go and check them.

Written in plain language on purpose. Every one of them is verifiable in the public repo before you spend a cent.

One command starts all three apps

Your product, its admin panel, and the API boot together with pnpm dev, already talking to one Postgres and sharing one set of types.

Mistakes surface while typing, not in production

Types run from the database column to the button. A wrong guess is a red underline in the editor, not an incident report.

Every feature is a folder

Both sides are organized by domain, so handing work to a new developer, or an AI agent, is a folder instead of a tour.

You can read every line before you spend anything

The whole starter is public on GitHub. Clone it, judge how it is put together, keep the code either way.

The business case

Months of work you don't pay for

What the starter changes for the person paying: time, money, and the risk of a rebuild.

time

3+ months

done for youyour product

The screens and plumbing a build spends its first months on, already in the repo.

money

to start building

The starter is free and public. You pay for feature packs later, or never.

hiring

Vite

bundler

oxc

linter

tsgo

type checker

pnpm

packages

monorepo

TanStack

router

Ordinary, popular tools. The next developer you hire has used every one of them.

risk

Code in your repo
Standard Postgres
No hosted lock-in

Walk away any time. There is nothing to migrate off.

Deploy with one command.

One command puts all six services live on your own hosting account. No dashboards, no YAML.

Creates every service on your host
Wires the URLs, secrets, and CORS between them
Runs your migrations once the API is up

Fly.ioRailwayyour account, either way

launch sequence

one command

Applicationlive
Admin Panellive
APIlive
Media Storagelive
Databaselive
Cachelive

https://my-app.com0 / 6 live

Try to break it

Rename a column. Every layer notices.

One name, declared once in the database and inherited by every layer above it. Catching this while typing is cheaper than catching it in production.

one field, five layers

organization.seat_limit

start: the database

Postgres
the column
seat_limit integer
Prisma
the schema
seat_limit Int
Kysely
the query
.select("seatLimit")
Hono
the API route
c.json({ seatLimit })
React
the UI
{data.seatLimit}

end: the button your users click

what this buys youpnpm typecheck: 0 errors

The compiler finds every screen that breaks
Change a field and every affected query, route and component shows up as a list. Nothing waits to be discovered in production.
Refactors stop being scary
Rename, restructure, then follow the errors to done. When the list is empty, the change is complete everywhere.
AI agents fix their own mistakes
A wrong guess fails the typecheck in seconds. The agent reads the error and corrects itself instead of shipping broken code.
Three apps that cannot drift apart
Frontend, backend and admin read the same types, so an API change never leaves one of them quietly behind.

Nobody wrote a test for any of this. It is what the compiler already does when every layer shares one set of types.

Being straight with you

What the starter does not include.

Better you read it here than find out on day two.

Auth, billing, notifications, collaboration

Feature packs. One command installs each across the stack.

Browse feature packs

A finished look

The starter ships a neutral theme. Templates bring a skin.

Browse templates

The three apps

What each one is made of.

Ordinary choices, on purpose. Anything here, a developer you hire has already used.

Frontend

React 19 and TanStack Router. Desktop from the same code.

React 19TanStack RouterTailwind v4shadcn/ui

Backend

Hono routes, Zod at the edge, Prisma and Kysely.

HonoPrismaKyselyPostgres

Admin panel

Own entry, own login. The free template ships the shell.

Separate entryOwn authDashboard shell

Shared infrastructure

One Postgres, one Valkey, one docker compose up.

PostgresValkeyShared types

One install, one dev command, one set of types.

The details

Show this part to your developer.

Current versions, pinned. Vetting this stack takes an afternoon, not a discovery phase.

3
apps, one dev command: 5
layers, one field name: 0
hand-written API clients: 56
editable shadcn components

Workspace: Nx 23 over pnpm. Three apps, three e2e projects.
Frontend: React 19, TanStack Router and Start, Tailwind 4, Zod 4.
Backend: Hono 4, Prisma 7, Kysely, HyperFetch, CASL 7.
Infrastructure: Postgres 17 on the pgvector image, plus Valkey.
Toolchain: Vite 8, oxlint, oxfmt, TypeScript 7 native, Vitest 4.
Targets: build:web, build:ssr on Nitro, make:app on Electron 43.

Full technology list

Everything in the box

What the starter already handles.

The plumbing below is finished before you write a line. All of it is checkable in the public repo.

Database setup

Postgres set up and ready for development: local database, migrations, and typed queries all work out of the box.

Desktop app shell

One shell that runs in the browser and as a native window, title bar and all. Ship a downloadable app without a second codebase to maintain.

SSR, CSR, or desktop

One codebase builds a static site, a server-rendered app on Nitro, or an Electron desktop app. Change targets without a rewrite.

Type-safe API calls

Typed end to end with HyperFetch and Hono. Change a route and the frontend stops compiling. You catch bugs while typing, not from a user report.

Type-safe WebSockets

Every realtime event is typed end to end through HyperFetch. No guessing payload shapes, no stale event names slipping into prod.

Realtime ready on day one

Auth-aware WebSockets already wired. Live updates and collab features become an afternoon of work, not a quarter.

Feature packs to grow with

Every pack ships real source code: frontend, backend, and admin surfaces where the feature needs them. Add them when you need them, one command each.

FeatureBilling (Stripe)Stripe integration, subscriptions, billing flows, and an admin revenue widget.Stripe checkout & portalSubscription plans FeatureWhiteboardA collaborative whiteboard: sticky notes, freehand ink, shapes, images, and layers on one infinite canvas, synced live.Infinite canvasLive multiplayer FeatureProjectsOrg-scoped projects with members, favorites, icons, and a navbar switcher.Project CRUDMembers & roles FeatureTeamsTeam workspaces with members, roles, icons, and email invitations on top of your starter.Team workspacesMember roles

See all 12 packs

Two ways to install features

Same features underneath, different starting point. Either command resolves what the packs depend on, copies the source into your repository, and merges the database schema.

Ready-made

Take a template

A landing page, a design system, a themed layout, and the features already wired into it. Rebrand it, put your product in the middle, ship.

Browse templates

From scratch

$ hype-stack compose

✓ Auth✓ Billing✓ Teams✓ AI

Compose your own design

Your design and your choices, without rebuilding auth, billing, or notifications. Tick the packs you want and the CLI wires them into the open-source starter.

Browse packs

Questions, answered

Yes. Everything lands as plain source in your repository: frontend, backend, admin, database schema. There is no runtime dependency on us and nothing phones home.

Take the free one. Decide nothing else today.

Clone it, run it, see if you like how it is put together. Packs come later, or never.

Get the repo Installation guide

free / public / your repo

Three apps.One codebase.

Frontend

Backend

Admin panel

SSR, CSR, or desktop? Choose later.

Google reads every page

Weeks of screens, already in the repo.

Three apps to start. Add more as you go.

Four claims. Go and check them.

Deploy with one command.

Rename a column. Every layer notices.

What the starter does not include.

Auth, billing, notifications, collaboration

A finished look

What each one is made of.

Show this part to your developer.

What the starter already handles.

Feature packs to grow with

Two ways to install features

Take a template

Compose your own design

Questions, answered

Take the free one. Decide nothing else today.

Three apps.
One codebase.