ARCH-9 Tech Due Diligence

Tech Due Diligence ARCH-9: Frontend Architecture and User Experience Performance

What This Control Requires

The assessor evaluates the frontend architecture, including component structure, state management, rendering performance, bundle size optimisation, accessibility compliance, and the overall user experience engineering quality.

In Plain Language

For B2B SaaS products, a sluggish or inconsistent frontend directly impacts customer satisfaction, churn, and competitive positioning. Frontend technical debt is particularly insidious because users feel it immediately - slow page loads, janky interactions, and broken layouts all shape how customers perceive your product.

Assessors examine the frontend framework choice and its appropriateness, component architecture (reusable composable components vs. monolithic page components), state management approach, rendering performance (Core Web Vitals, Time to Interactive), bundle size and code splitting strategy, accessibility compliance (WCAG 2.1 AA), and responsive design across devices.

The key question is whether the team treats frontend engineering with the same rigour as backend engineering. Performance degradation, inconsistent UI patterns, accessibility failures, and bloated bundles are all signals that the frontend has been deprioritised - and that means user experience problems will compound as the product grows.

How to Implement

Adopt a component-based architecture using a modern framework (React, Vue, Svelte, Angular). Define a clear component hierarchy: design system tokens (colours, typography, spacing), primitive UI components (buttons, inputs, modals), composite components (forms, data tables, navigation), feature components (specific to business domains), and page components (composition of feature components for routes).

Build a design system or component library to ensure visual and behavioural consistency across the application. Use tools like Storybook to document and showcase components. A solid design system reduces development time, improves consistency, and makes the application significantly more maintainable.

Optimise frontend performance by implementing code splitting and lazy loading for routes and large components, keeping bundle size lean through tree shaking, compression, and dependency auditing, monitoring Core Web Vitals (LCP, FID, CLS), optimising images (responsive images, lazy loading, modern formats), and using caching strategies for static assets.

Choose a state management approach that matches the application's actual complexity. For simpler applications, built-in state management (React Context, Vue reactive state) is often enough. Complex applications with significant client-side state benefit from dedicated libraries (Zustand, Redux Toolkit, Pinia). Avoid over-engineering state management for straightforward use cases.

Bake accessibility into the development process from the start rather than bolting it on later. Target WCAG 2.1 AA compliance at minimum. Use semantic HTML, ARIA attributes where needed, keyboard navigation support, sufficient colour contrast, and screen reader testing. Include automated accessibility checks in CI/CD using tools like axe-core or pa11y.

Monitor frontend performance in production using Real User Monitoring (RUM). Track Core Web Vitals, JavaScript error rates, and user interaction metrics. Alert on regressions before they become widespread user experience problems.

Evidence Your Auditor Will Request

Component architecture documentation or design system
Bundle size analysis and code splitting configuration
Core Web Vitals metrics from production monitoring
Accessibility audit reports or compliance assessment
Frontend testing strategy including component and integration tests

Common Mistakes

No component reuse; UI elements duplicated across pages with inconsistencies
Bundle size excessively large (>1MB) with no code splitting or lazy loading
No accessibility consideration; WCAG violations throughout the application
State management overly complex or inconsistent across the application
No frontend performance monitoring; performance issues only discovered through user complaints

Related Controls Across Frameworks

Framework	Control ID	Relationship
SOC 2	CC8.1	Related

Frequently Asked Questions

Is accessibility compliance really evaluated in tech DD?

Increasingly, yes. It affects market reach since public sector contracts often require WCAG compliance. It affects legal risk given the growth in accessibility litigation. And it signals engineering quality. For B2B SaaS specifically, enterprise customers may require accessibility compliance as a procurement criterion, so gaps here can limit your addressable market.

What is an acceptable bundle size for a SaaS application?

The initial load (critical path) should be under 200KB gzipped. Total application size can be larger if you have effective code splitting in place. A multi-megabyte initial bundle with no code splitting is a clear red flag - it tells assessors that frontend performance has not been a priority.

Track Tech Due Diligence compliance in one place

AuditFront helps you manage every Tech Due Diligence control, collect evidence, and stay audit-ready.

Start Free Assessment