Technical Approach
How this prototype was built, why those choices matter, and how the architecture scales to production.
Tech Stack
| Technology | Version | Purpose |
|---|---|---|
React | 19 (latest stable) | UI framework — concurrent features, Server Components, Suspense boundaries |
Storybook | 10 | Component development environment — this deliverable is built entirely in Storybook first, pages second |
Tailwind CSS | 4 (v4.1+) | CSS-first configuration via @theme directive, OKLCH color space, zero runtime overhead |
shadcn/ui | Latest (Radix UI) | Accessible primitive components — Dialog, DropdownMenu, Tabs, Select with ARIA compliance built in |
TypeScript | 5.7+ | Strict mode enabled, no any, template literal types for variant APIs |
Vite | 7 (latest) | @tailwindcss/vite plugin, tree-shaking, code splitting, sub-second HMR |
Radix UI | Via shadcn/ui | Headless UI primitives — keyboard navigation, focus management, ARIA patterns |
AXE (addon-a11y) | Via Storybook | Automated WCAG 2.1 AA testing runs on every story automatically — zero violations required |
Lucide React | Latest | Tree-shakeable SVG icon library — 1000+ icons, consistent 2px stroke weight |
Speed as Currency — The Evidence
72 hours. Not 8 weeks.
This prototype — complete with design token system, foundation documentation, component library (atoms, molecules, organisms, templates, full pages), foundational design direction, phased implementation roadmap, and 67+ production components — was built using AIQ Cortex, AgencyQ's AI-accelerated development platform. Using a traditional approach this would typically take 6-8 weeks. We delivered it as a demonstration.
72 hrs
Time to build this prototype
6–8 wks
Traditional agency timeline
~5×
AgencyQ speed advantage
67+
Production components shipped
The speed advantage is structural. AIQ Cortex allows the development team to compress the boilerplate-writing phase (which accounts for 60–70% of traditional build time) while keeping humans in control of architecture and design decisions. The result: more iterations in less time, more room to test directions, faster time to first production deploy.
Three-Layer Token Architecture
The design system uses a three-layer architecture that separates values from meaning from components. This is what makes brand evolution instant and makes any designer on Kastle's team capable of updating the brand.
Layer 1
Primitives
Raw values. No meaning attached.
--color-brand-500: #E2242A
--color-neutral-800: #333333
--space-4: 1rem
--radius-md: 9px
Layer 2
Semantics
Meaningful aliases. Context-aware.
--color-text-primary: var(--color-neutral-800)
--color-surface-default: white
--color-interactive-default: var(--color-brand-500)
--focus-ring-color: var(--color-brand-500)
Layer 3
Components
Component-specific overrides.
--button-bg: var(--color-interactive-default)
--card-padding: var(--space-6)
--nav-height: 80px
--hero-height: 630px
How the token architecture works: Components never reference raw color values. They consume semantic tokens that chain through three layers: primitives (raw values), semantics (purpose-mapped), and component tokens (specific overrides). Brand evolution is a CSS variable change, not a codebase rewrite.
Platform-Agnostic Integration
This component library does not require a platform migration. It works with Kastle's existing stack.
WordPress (Current)
Low
React components embed via WordPress block plugins or shortcodes. No WP theme overhaul needed. HubSpot forms and Dynamics integrations remain untouched.
Headless CMS
Medium
Contentful, Sanity, or Prismic as content layer. Next.js frontend renders components server-side. Maximum performance and editorial flexibility.
HubSpot CMS
Low
HubSpot's React-based template system supports this component library directly. HubSpot forms connect natively to Dynamics CRM pipeline.
Full Next.js
High (Phase 3)
Best performance, best SEO, maximum control. React Server Components reduce JavaScript sent to browser. Incremental Static Regeneration for marketing pages.
Bottom line: We don't force a platform decision on day one. We recommend starting with the WordPress + React hybrid approach (Phase 1, fastest to value), then evaluating a headless migration in Phase 2 based on traffic and editorial team requirements.
Quality Standards
Every component in this prototype is held to these standards. Non-negotiable.
WCAG 2.1 AA
Enforced
AXE automated testing runs on every Storybook story. Zero violations required before a component ships. Color contrast, focus indicators, ARIA labels — all verified.
TypeScript Strict Mode
Enforced
No any. No type assertions without justification. Template literal types for component variant APIs. Discriminated unions for component state.
80%+ Test Coverage
Target
Unit tests for utilities and hooks. Interaction tests via Storybook play() functions. E2E tests for critical conversion flows (form submit, CTA click, navigation).
Mobile-First Responsive
Enforced
Every component designed for 375px first, enhanced for 640/768/1024/1280px. Storybook viewport addon used for verification at each breakpoint.
Lighthouse 90+ Target
Target
Performance: code splitting at route level, lazy loading for below-the-fold content, AVIF/WebP images. SEO: semantic HTML, structured data, proper heading hierarchy.
No Console Errors
Enforced
Zero JavaScript errors in production builds. Zero console.log statements. Zero unhandled Promise rejections. Error boundaries on all major sections.
See It In Action
Production-ready code, live in this browser
Live Demo
Pages → Homepage
67+ components assembled into a full working homepage. Production-ready.
Sprint Plan
Context → Sprint Plan & Roadmap
Phased delivery plan. What ships in Week 1 vs. Week 12.
ROI Model
Context → ROI Model
Conservative, moderate, high scenarios. All assumptions disclosed.
Overview
Context → Overview
Priority framing and delivery sequence used to phase implementation.