Open-source frontend foundation

The frontend decisionsare already made.

Atlas is a forkable Next.js foundation where architecture, application infrastructure, testing, and delivery already work as one system—so your team can start with the product, not the setup.

Explore the reference appView the repository
corepack enable && pnpm install && pnpm validate:env && pnpm dev
apps / web / src / features / users / queries.ts
Source
export function useUserList(params?: { page?: number }) {
  return useQuery<UserListResponse, ApiError>({
    queryKey: userKeys.list(params),
    queryFn: async () => {
      return api.users.list(params);
    },
  });
}
Showing apps/web/src/features/users/queries.ts

Atlas product properties

01

Coherent by default

UI, data, auth, errors, observability, and product state follow one shared set of conventions.

02

Production included

Accessibility, logging, analytics, testing, and CI are part of the foundation from day one—not work deferred until launch.

03

Fully yours

Fork the codebase, remove the examples, replace integrations, and evolve the architecture with your product.

Everything included

Make the recurring
decisions once.

Atlas brings the architecture, infrastructure, tooling, and production conventions together as one foundation—so teams don't have to assemble them again for every product.

Atlas/Capabilities

Atlas is not just a bundle of libraries. It encodes a coherent frontend architecture: thin Next.js App Router routes, feature modules that own domain logic with no cross-feature imports, shared infrastructure in lib/, reusable primitives in packages/ui, and shared tooling in packages/.

  • Thin App Router routes in apps/web/src/app/
  • Feature modules with no cross-feature imports
  • Shared infrastructure in apps/web/src/lib/
  • Reusable primitives in packages/ui/
  • Shared ESLint & TypeScript config in packages/
  • Turborepo + pnpm workspaces
atlas/
atlas/
├── apps/web/src/
│   ├── app/              # Routes & layouts — thin pages only
│   ├── features/         # Domain modules — no cross-feature imports
│   ├── lib/              # API, auth, telemetry, shared infra
│   └── schemas/          # Zod validation
├── packages/
│   ├── ui/               # Reusable primitives (@atlas/ui)
│   └── config/           # ESLint, TypeScript, shared tooling
├── openapi/              # API contract
├── turbo.json            # Turborepo task pipelines
├── pnpm-workspace.yaml   # pnpm workspaces
└── AGENTS.md             # Ownership boundaries

Built with Atlas

One foundation.
Different products.

Atlas has been used across knowledge products, developer infrastructure, and production applications—without forcing them into the same product shape.

Aviatopia

Built from Atlas

Built from Atlas

xGas Station

Built from Atlas

Migrated toward Atlas

End-to-end types

One contract. One path to the interface.

From the source contract to the generated client, feature module, and product UI, Atlas keeps the path typed end to end.

Contract to product path in AtlasOpenAPI contract flows through generated client and typed feature module to product UI, supported by the Atlas foundation and verified by typecheck, tests, and production build.
  • Typecheck
  • Tests
  • Production build
  1. OpenAPI

    OpenAPI

    Source contract

    openapi/openapi.json

  2. Generated client

    Generated client

    SDK + TypeScript

    lib/api/contracts

  3. Feature module

    Feature module

    Domain boundary

    features/users

  4. Product UI

    Product UI

    React interface

    apps/web

Atlas foundation

Agent context

Any agent.
Same architecture.

Change your agent, not your engineering standards.

Architecture rules, feature boundaries, reference implementations, and verification live in the repository—so every coding agent works from the same context.

Agent context transcript

Interactive transcript showing that any coding agent loads the same Atlas repository context. Only the agent flag in the command changes.

$ context --agent cursor

  1. Reading AGENTS.md

    Repository architecture and conventions loaded

  2. Locating feature boundary

    apps/web/src/features/users

  3. Finding reference implementation

    apps/web/src/features/examples

  4. Applying repository conventions

    Thin routes · feature ownership · no cross-feature imports

  5. Verifying implementation

    validate:env · lint · typecheck · test · build

Architecture preserved

No black boxes

Inspect the decisions,
then make them yours.

Atlas is source code, documented decisions, and explicit conventions—not a runtime you rent. Inspect how it works, keep what earns its place, and change what doesn't.

Inspect

Change

  • KEEPpackages/uiShared primitives
  • REPLACEAuthentication providerBring your own auth integration
  • EXTENDFeature managementAttach your own monitoring or flagging stack
  • CHANGE.github/workflowsVercel, AWS, self-hosted, or your preferred delivery path
  • EDITAGENTS.mdYour team's conventions
  • Your repository
  • Replaceable integrations
  • No hosted dependency

Built from practice

I built Atlas from the frontend
problems I kept solving.

I'm Daniel Mark, a frontend engineer and consultant. Atlas is the reference implementation behind the way I build product frontends: clear ownership boundaries, typed contracts, reusable UI, production infrastructure, and engineering conventions that stay consistent as the product grows.

If your team is starting a new frontend, outgrowing an inconsistent codebase, or trying to make AI-assisted development safer, I can help apply the same principles to your product.

Daniel Mark

Frontend engineer & consultant

Foundation from day oneStacked architecture layers built incrementally from a shared foundation.

Starting from scratch

Design and implement a frontend foundation for a new product with clear boundaries, shared infrastructure, typed contracts, reusable UI, testing, and delivery conventions from day one.

Architecture · Next.js · Design systems · CI

Incremental migrationDrifted modules reorganized into clearer ownership boundaries without a rewrite.

Your frontend is getting harder to change

Audit the current architecture, identify where ownership and infrastructure have drifted, and migrate the codebase toward clearer boundaries without requiring a full rewrite.

Architecture audits · Migrations · Platform cleanup

Agent verification gatesMultiple agent paths routed through repository rules and quality gates.

AI is increasing output faster than consistency

Encode repository conventions, reference implementations, ownership rules, and verification gates so engineers and coding agents can move quickly without bypassing the architecture.

Agent context · Repository rules · Quality gates

Talk about your frontendSee how I work

FAQ

Questions teams ask
before they adopt Atlas.

Atlas is opinionated by design. These are the questions that usually matter before making it part of a codebase.

Work with me

Bring this approach
to your frontend.

Whether you're starting a product, cleaning up an existing frontend, or trying to make agent-written code more predictable, I can help design and implement the foundation with your team.

Talk about your frontendView the repository