Devsuite

Brand

Color mode

Contrast

Devsuite

Build products, systems, and experiments from one reusable foundation

Devsuite is a personal platform monorepo for building almost anything from one reusable foundation. The original brief was not "make one app." It was "build the toolkit you wish you always had": a world-class design system, a reference SaaS workspace, reusable product primitives, infrastructure recipes, prompt assets, and clear paths into native and Rust work.

This repository is the first serious pass at that brief.

Read the docsBrowse StorybookJump to roadmap

README-driven copy

Public surface

SSR by default, Directus when you want authoring

No Directus endpoint is configured, so the page is reading the README and roadmap files directly.

  • RepoHero copy

    Waiting on Directus document landing-hero; using the repo file instead.

  • RepoMotivation section

    Waiting on Directus document landing-motivation; using the repo file instead.

  • RepoVision section

    Waiting on Directus document landing-vision; using the repo file instead.

  • RepoProgress section

    Waiting on Directus document landing-progress; using the repo file instead.

  • RepoRoadmap section

    Waiting on Directus document landing-roadmap; using the repo file instead.

Apps live

3

Public docs, the reference workspace, and now the landing surface all dogfood the shared foundation.

Design system layers

5

Tokens, theming, primitives, composed components, and testing all exist today.

Shared platform zones

13

Auth, billing, content, databases, infra, tooling, native, and Rust starter paths are already mapped.

Roadmap phases

5

The plan moves deliberately from foundation hardening to cloud and automation.

Motivation

Why Devsuite exists

The original brief was bigger than a single app: build the toolkit you wish you always had, then keep it coherent as it grows.

README

The brief

The original brief was bigger than a single app: build the toolkit you wish you always had, then keep it coherent as it grows.

What the repo set out to include

  • a sophisticated monorepo that can act as a long-term personal development suite
  • a world-class component library at the center, with React Aria quality and WCAG AAA intent
  • tokens, multi-brand theming, Storybook, and a path toward Penpot alignment
  • reusable primitives for logging, payments, auth, content, prompts, infrastructure, and databases
  • room for Rust, iOS, Android, CMS patterns, and cloud deployment strategies
  • documentation and operating discipline so the system can keep evolving without becoming chaotic
Vision

A coherent foundation instead of a stack of one-offs

Devsuite is designed to make new ideas start from a reusable foundation instead of from scratch.

README

How the suite stays coherent

Devsuite is designed to make new ideas start from a reusable foundation instead of from scratch.

The north star for Devsuite is simple:

North-star defaults

  • start new ideas from shared tokens, UI primitives, domain packages, and delivery habits instead of from scratch
  • keep accessibility, testing, and documentation as defaults rather than cleanup work
  • make the repo useful for product work, tinkering, server operations, and future experiments
  • grow deliberately into native, cloud, and automation surfaces without losing coherence
Progress

What already exists, and what is queued next

Phase one is already tangible across apps, shared packages, and platform zones, and the README keeps that status legible.

README

Apps

  • apps/site: SSR landing page for devsuite.amhomelabs.com, driven by the README and roadmap files with optional Directus section overrides
  • apps/docs: static React Router handbook for strategy, architecture, planning, runbooks, and prompts
  • apps/workspace: SaaS-shaped reference workspace proving auth, billing, logging, prompts, and database recipe integration

Design System

  • packages/tokens: canonical DTCG-style token source
  • packages/themes: vanilla-extract contract and multi-brand theme runtime with brand, light/dark, and contrast modes
  • packages/ui-primitives: React Aria powered primitives with accessible defaults
  • packages/ui-components: composed shells, theming, Storybook stories, and shared page-level components
  • packages/testing: shared design-system and QA helpers

Product Primitives

  • packages/auth-core and packages/auth-dev
  • packages/billing-core and packages/billing-stripe
  • packages/content-core and packages/content-fs
  • packages/content-directus
  • packages/logging
  • packages/db-postgres, packages/db-mysql, and packages/db-sqlite
  • packages/prompts

Platform Zones

  • infra/docker: local-first database stack
  • infra/aws: placeholder for later SST or AWS patterns
  • tooling: internal Nx plugin and generators
  • rust/devsuite-cli: Rust workspace starter
  • native/ios and native/android: native token-consumption placeholders
  • planning: local delivery system, backlog seeds, templates, and board conventions

Done

  • monorepo foundation
  • docs app and reference workspace
  • token and theme pipeline
  • Storybook globals for multi-brand and mode-aware review
  • initial product primitives
  • Storybook, Vitest, Playwright, and CI baselines
  • AWS-hosted Storybook infrastructure and GitHub OIDC provisioning path

Next

  • deepen the design-system coverage and accessibility governance
  • harden the workspace primitives with real adapters and contract tests
  • enrich docs and planning into a reliable operating system
  • tighten access control and publication rules for the hosted Storybook review surface
  • turn the DSM strategy into an implementation slice when structured content pressure is high enough
  • start the Penpot, native token export, and cloud research spikes

Later

  • real auth providers
  • richer billing workflows and webhook contracts
  • CMS integration path
  • native component libraries
  • AWS or SST deployment abstractions once local-first recipes are mature
Roadmap

Phased growth without losing the plot

The roadmap is intentionally phased. The goal is not to build every capability at once. The goal is to compound confidence and leverage.

Roadmap and next steps

Phase 0

Foundation is in place.

  • monorepo structure exists
  • docs and workspace apps exist
  • token and theme pipeline exists
  • first-pass product primitives exist
  • CI, Storybook, unit tests, and browser tests exist

Phase 1

Design system hardening.

  • expand primitive and component coverage
  • shipped the first coherent primitive wave in the docs-first workflow: Link, TextArea, Checkbox, and Switch
  • shipped the second coherent primitive wave in the docs-first workflow: Accordion, Dialog, Tooltip, Notification, Text, Paragraph, and Strong
  • shipped the third coherent primitive wave in the docs-first workflow: DateField, Dropdown, NumberField, RadioButton, SearchField, and Selector
  • shipped the fourth coherent primitive wave in the docs-first workflow: DatePicker, DateRangePicker, ComboBox, Menu, ErrorSummary, and FieldError
  • shipped the fifth coherent primitive wave in the docs-first workflow: Calendar, ProgressBar, Spinner, SummaryBox, and Confirmation
  • add an accessibility exception register and review discipline
  • improve Storybook coverage so every public component state is documented
  • make Storybook publishable to a private review surface
  • deepen token exports for future Penpot and native consumption
  • keep the docs-native component workbench and token explorer aligned with the shipped primitives

Phase 2

Reference workspace hardening.

  • choose a real auth provider strategy after a spike
  • deepen billing flows beyond the deterministic Stripe test adapter
  • strengthen content and prompt management patterns
  • decide when the CMS-backed DSM path is worth turning into a real app surface
  • add richer logging sinks and operational diagnostics

Phase 3

Platform expansion.

  • implement token export paths for native consumers
  • run the Penpot integration spike and decide the long-term contract
  • deepen Rust utilities where they provide clear leverage

Phase 4

Cloud and automation.

  • harvest reusable SST or AWS patterns from real product work
  • add deployment recipes once local-first flows are mature
  • use the Storybook hosting slice as the first proven GitHub OIDC deployment path
  • extend observability and release automation

Immediate next steps

  • use the component workbench and token explorer as the default review path for every new primitive
  • follow the shipped fifth primitive wave with richer table, slider, layout, and document-structure primitives so more of the docs and CMS surface can dogfood the shared system
  • tighten Storybook access control now that the first GitHub-hosted publish is live
  • build on the new docs-site DSM foundation with a CMS authoring pilot once the content schema is ready
  • pressure-test the Directus MVP locally before promoting CMS-backed content into a public docs path
  • use the workspace to pressure-test every shared package change
  • keep documentation and planning current as the suite gains capabilities