The Challenge: Enterprise Standardization at Scale Statsbygg manages over 2.3 million square meters of government buildings. Their development teams were operating with fragmented tooling, inconsistent patterns, and no unified architecture. Each project reinvented solutions for common problems: design inconsistencies, repeated boilerplate, and lack of shared standards.
The organization needed a way to scale development velocity while maintaining code quality and visual consistency. The solution had to provide executable infrastructure that enforced best practices by default while remaining flexible for domain-specific needs.
The Solution: A Cohesive Package Ecosystem I designed a monorepo architecture housing five interconnected internal packages, each solving a specific dimension of the standardization problem. The system revolves around Next.js, TypeScript, and the official Norwegian government design system (DigDir Designsystemet).
Project Initializer: This command-line tool is used to kickstart entirely new frontend projects. It uses the other packages and predefined templates to create a fully configured Next.js application, complete with the design system, component library, generators, and standard architectural patterns already set up. Projects can be scaffolded in under 60 seconds with all dependencies, linting, and formatting pre-configured.
Visual Foundation: This package acts as the visual foundation of the entire ecosystem. It takes design specifications (colors, fonts, spacing) from the DigDir Designsystemet and compiles them into CSS custom properties (variables). This ensures all applications share a consistent look and feel and supports features like light/dark mode easily. The tokens follow a multi-tier hierarchy: primitive tokens define raw values, semantic tokens alias primitives with meaning, and component tokens consume semantic tokens for specific use cases.
Reusable UI Building Blocks: Building upon the design tokens, this package offers a library of reusable UI components specific to Statsbygg's needs. These components complement the base DigDir components, reducing code duplication across different applications. All components follow strict TypeScript typing, comprehensive Storybook documentation, and achieve high test coverage with Vitest.
Shared Structural Components: This package provides shared structural components like headers, footers, and breadcrumb systems. It's designed particularly for scenarios where multiple frontend applications need to present a unified user experience, such as in a microfrontend architecture. It includes mechanisms for managing basic global state (like theme or user info) across these applications.
Developer Productivity Engine: This is the developer productivity engine - a collection of command-line tools that automatically generate boilerplate code for common structures. Developers can generate components, API integration layers, forms with validation, state management stores, and application routes, all adhering to Statsbygg's defined patterns. This dramatically reduces repetitive work and ensures consistency.
Design Token Compilation & Theming The design token system is the backbone of visual consistency. I built a custom Node.js build script that processes design specifications and outputs multiple formats: CSS custom properties for runtime theming, TypeScript constants for type-safe access in components, and Figma Tokens JSON for design tool integration.
The compilation process validates token references, checks for circular dependencies, and generates comprehensive documentation automatically. This documentation site shows all tokens with live previews, usage examples, and accessibility contrast ratios for color pairings, becoming the single source of truth for both designers and developers.
The theming system supports light and dark modes out of the box. Since all styling is driven by CSS custom properties, switching themes is as simple as swapping the root-level token values. This made implementing the government-mandated accessibility features straightforward.
CLI-Based Development Workflow The generator tools transformed how developers work. Instead of copying boilerplate from previous projects or writing repetitive code, developers run simple CLI commands that generate complete, pattern-compliant features.
For example, generating a new API integration layer creates all necessary files: the API client functions, TypeScript types, TanStack Query hooks for data fetching, error handling, and loading states - all wired together and ready to use. The generated code follows the exact patterns established by the team, ensuring every developer produces consistent work.
The create-app tool handles project initialization with an interactive prompt system. It asks questions about the project (authentication providers, database connections, deployment targets) and scaffolds a complete application configured specifically for those choices. The resulting project includes Git initialization, ESLint/Prettier configuration, and connections to the shared component library.
Adoption & Impact Within two months of release, the ecosystem was adopted by two internal teams. Scaffolding time for new projects dropped from 3-4 days to under one hour. The shared component library reduced UI inconsistencies by an estimated 70% based on design review feedback.
The generators became particularly popular - developers used them extensively in the first month to avoid writing boilerplate for API integrations and form handling. The time saved on repetitive tasks allowed teams to focus on domain-specific features rather than infrastructure setup.
The system is designed to evolve. Each package is versioned independently, allowing incremental adoption. Teams can upgrade the design tokens without touching their code generation tooling. This loose coupling was critical for achieving buy-in from teams with existing codebases who couldn't afford a full migration.
