EmerusLabs Starter

An EmerusLabs starter built from real app concerns.

Auth, data and reusable app structure are already wired so the starter feels like a product, not a demo.

Core Areas

Auth

Email OTP and passkeys already wired.

Data

Protected example data scoped to each user.

Scroll to explore

Starter Baseline

The first build starts from real product concerns, not setup chores.

01

Start from product shape

Core product concerns are already wired, so first work starts from a usable baseline instead of a blank scaffold.

02

Keep one shared system

Homepage surfaces, route states, dialogs, and shared shell primitives all stay inside the same token-driven UI system.

03

Extend without rewrites

Protected routes, and app-level utilities are shaped as reusable product pieces, not disconnected demos.

Architecture Flow

How the starter turns tooling into shipped product behavior.

01

Runtime + Tooling

Bun, Vite, Biome, and `tsgo` keep the loop fast.

The starter already ships with a modern local workflow, typed builds, and code quality tooling wired into the project.

Bun scripts
Vite app runtime
Biome checks
TypeScript native preview
02

Shell + Routing

Shared chrome and route-level boundaries.

Header, footer, dialogs, and route surfaces stay consistent while TanStack Router drives staged routes and protected flows.

Shared app shell
Route boundaries
Homepage preview route
Scroll restoration
03

Auth

Passwordless sign-in without a route maze.

Better Auth handles email OTP and passkeys through a single auth flow instead of page-by-page reinvention.

Email OTP
Passkeys
Session-aware shell
Profile dialog
04

Backend + Data

Convex backs the app shape, not just storage.

Schema, user records and example data already exist as backend primitives the UI can build on.

Convex schema
Auth-aware queries
User-owned example data
Shared validators
05

Telemetry

Analytics and devtools are already part of the starter.

Databuddy and TanStack devtools are wired into the root document so the starter begins with observability instead of adding it later.

Databuddy wiring
Router devtools
Query devtools
Config-driven setup

Technology Choices

Why these tools are in the starter, not just which ones are installed.

Selected layer

Convex

Backend + Data

Owns schema, app data and auth-aware queries.

Why it is in the starter

Chosen because the starter needs one backend shape that can cover auth-aware reads, product data, and reusable app primitives without splitting the stack too early.

What it brings

One backend model for example data
Auth-aware queries already fit the signed-in app shell
Backend primitives are ready before product code starts branching

Supporting packages

Extension points around Convex

@convex-dev/react-query

Bridges Convex and TanStack Query so backend reads fit the app-level data model.

Open The Proof

Open the routes that show the starter already behaves like an app.

Interactive proof

Protected example workspace

The `/example` route demonstrates an authenticated boundary with user-owned data.

Interactive proof

Passwordless auth modal

Email OTP and passkeys are already wired through one sign-in experience.

Also already wired

Useful app-level pieces that support the baseline.

Telemetry + devtools

Analytics and TanStack tooling are already part of the root app shell.

Env-backed app configuration

App title and analytics wiring already respect config-driven setup.

EmerusLabs Standard

The standards and learnings behind how this starter is put together.

Learnings from EmerusLabs

The starter follows the same practical bias behind EmerusLabs.com: build around real app concerns, keep shared primitives intact, and prefer structures that can survive actual product work.

Real app concerns before framework bragging.

Shared primitives before route-by-route reinvention.

Known dependencies before hidden platform magic.

Starter-first UX with room for product and client work to grow from it.