8.5 KiB
Requirements — React Frontend (SLP Software Marketing Site)
Intent Analysis Summary
- User Request: Build a React frontend for SLP Software. Two static HTML reference designs exist in
References/(slp-software.html= purple accent,slp-software-rood.html= red accent) that are the same design with only a different accent color. Red must become the primary/default theme; the purple theme must remain selectable (this selectability is new, not present in the original static designs). All other content/layout must be ported 1-to-1 into React. Start with a static site, but built as React. For later use: TanStack Router and TanStack Query should be used where needed. The AI-DLC workflow must be used to set this up. - Request Type: New Project (Greenfield)
- Scope Estimate: Single Component — one marketing/landing page rebuilt as a React application, plus supporting theming infrastructure
- Complexity Estimate: Simple to Moderate — the visual/content scope is a single static page, but a full modern tooling skeleton (Vite, TypeScript, TanStack Router, TanStack Query, Tailwind CSS, theming) is being set up for future growth
- Requirements Depth: Standard
Reference Design Analysis
Both reference files were compared byte-for-byte (Compare-Object). They are identical in structure, markup, and copy; the only differences are CSS custom property values used for theming:
| Variable | Purple (slp-software.html) |
Red (slp-software-rood.html) |
|---|---|---|
--bg |
#0E1220 |
#140C0E |
--surface |
#151A2C |
#1F1315 |
--surface-2 |
#1B2138 |
#291719 |
--line |
#262E4A |
#402226 |
--text |
#E9EBF5 |
#F5EAEB |
--muted |
#98A0BA |
#B69C9F |
--accent |
#8B7CFF |
#E04848 |
--accent-soft |
rgba(139,124,255,.14) |
rgba(224,72,72,.16) |
--accent-line |
rgba(139,124,255,.35) |
rgba(224,72,72,.40) |
Hero radial gradients, badge/button text color, #pakketten gradient |
purple-tinted values | red-tinted values |
Page structure (both files, identical):
- Nav — logo ("SLP.Software"), links (Pakketten / Werkwijze / Over), CTA ("Start project")
- Hero — eyebrow label, H1, lead paragraph, animated code line with blinking caret, two CTA buttons
- Pakketten (Packages) — 3 pricing cards (Landingspagina €300, Website €750 — featured, Maatwerk — quote-based)
- Werkwijze (Process) — 3-step process (intake, bouwen, live)
- Over (About) — company description + tech stack panel
- Contact — contact box with mailto CTA
- Footer — copyright + mono tagline
Functional Requirements
FR-1: Page Content Parity
The React application MUST reproduce all sections, copy, structure, and visual layout of the reference designs 1-to-1: Nav, Hero, Pakketten, Werkwijze, Over, Contact, Footer. All Dutch marketing copy, package prices (€300 / €750 / "Op maat"), and the contact e-mail address (info@slpsoftware.nl) are copied exactly as-is from the reference HTML for this iteration; this content is expected to be replaced by dynamically fetched data in a future iteration (see FR-5).
FR-2: Componentization
The page MUST be decomposed into reusable React components (e.g. Nav, Hero, PackagesSection, PackageCard, ProcessSection, AboutSection, ContactSection, Footer) rather than a single monolithic page component.
FR-3: Theme Switching
- The site MUST default to the red theme on first load.
- The purple theme MUST remain selectable by the visitor via a visible UI control (e.g. a toggle/switcher in the nav).
- The chosen theme MUST be persisted in the browser (
localStorageor equivalent) so it is remembered on return visits; if no stored preference exists, red is used. - Theme values MUST be implemented so that both palettes (and any future palette) can be added without duplicating component markup — i.e. only the color tokens change, not the structure.
FR-4: Preserved Micro-Interactions
All existing micro-interactions from the reference designs MUST be preserved: the blinking caret animation in the hero code line, :hover / :focus-visible states on links, cards and buttons, and smooth-scroll behavior for in-page anchor navigation (respecting prefers-reduced-motion).
FR-5: Forward-Looking Data Layer (Preparation Only)
- TanStack Router MUST be set up and wired into the application shell, even though the initial scope has effectively a single route (
/). Route structure should be organized so that adding routes later is straightforward. - TanStack Query MUST be installed and configured (e.g.
QueryClientProviderat the app root) as part of this iteration's skeleton, in preparation for a future iteration where package/content data is fetched from a backend instead of being hardcoded. No actual network data-fetching is required yet — static data (matching FR-1) is used as the source for now, structured so it can be swapped for a TanStack Query hook later with minimal changes.
Non-Functional Requirements
NFR-1: Tooling & Language
- Build tool: Vite
- Language: TypeScript
- UI library: React
NFR-2: Styling
- Tailwind CSS is used as the utility CSS framework to re-implement the reference visuals.
- The color palette (red default / purple alternate) MUST be modeled as design tokens (e.g. CSS custom properties consumed via Tailwind theme config, or a Tailwind theme extension keyed by a
data-themeattribute/class) so that switching a single token set changes the whole site's palette, mirroring how the reference designs use:rootCSS variables.
NFR-3: Browser Support
Modern evergreen browsers only (latest Chrome, Firefox, Edge, Safari). No legacy/IE-adjacent support required. This matches the reference design's use of modern CSS features (backdrop-filter, clamp(), CSS custom properties).
NFR-4: Deployment Target
The build output MUST remain a plain static bundle (HTML/CSS/JS, no Node.js server required at runtime) so it can be deployed to a traditional web host via FTP/manual upload. This has a design implication for TanStack Router: once more than one route exists, either hash-based routing or host-level rewrite rules (e.g. .htaccess) will be needed for direct-link/deep-link support on a plain static FTP host — to be finalized during Application Design / Infrastructure Design when routing needs are concrete.
NFR-5: Operations Phase
This feature WILL go through the Operations phase after Construction (deployment setup + monitoring setup + production readiness validation).
Extension Configuration
| Extension | Enabled | Notes |
|---|---|---|
| Security Baseline | Yes | Enforced as blocking constraints. Most backend-oriented rules (auth, API validation, network config, encryption at rest, etc.) are expected to be N/A for this static, no-backend marketing site — applicability will be re-assessed rule-by-rule at each stage (e.g. HTTP security headers via hosting/CDN config, dependency lock file & vulnerability scanning, Subresource Integrity for the Google Fonts CDN links). |
| Property-Based Testing | No | Skipped — this is a largely static, UI-only marketing site with no significant business logic. |
Out of Scope (for this iteration)
- Real backend/API integration for package/content data (prepared for via TanStack Query, but not implemented)
- Multiple routes/pages beyond the single landing page
- CMS or admin interface for editing content
- Analytics/tracking integration
- Automated deployment pipeline details (handled in the Operations phase)
Open Design Considerations (to resolve later, not blocking)
- Exact mechanism for FTP-safe client-side routing once multiple routes exist (hash routing vs.
.htaccessrewrites) — Application Design / Infrastructure Design. - Exact shape of the future data-fetching layer (API contract) that TanStack Query will eventually call — deferred until a backend exists.
Summary
This is a greenfield React frontend for SLP Software's marketing site. The visual and content scope is a straightforward 1-to-1 port of an existing static HTML/CSS design (available in two color variants). The key net-new requirement beyond the reference designs is a red-default / purple-selectable theme switcher with persisted preference. The project is set up with Vite + React + TypeScript + Tailwind CSS, and is scaffolded from day one with TanStack Router and TanStack Query to support future growth, even though the current scope has a single route and static data. Security Baseline is enforced; Property-Based Testing is skipped; the Operations phase will run after Construction.