Five services, five colours, one layout

Every service page on the site follows the same structure. A ServiceNav header with the service name and call-to-action buttons. A two-column layout — content on the left, a sticky ServiceSidebar on the right with an intake form or package selector. Cross-links to sibling services at the bottom. The layout is identical across all five pages. What changes is the accent colour. Sound engineering is cyan — hex 22d3ee. Music production is emerald — hex 34d399. Professional musician is orange — hex fb923c. Software engineering is purple — hex c084fc. Accessibility consulting is fuchsia — hex e879f9. The colour is set as a CSS custom property at the page level. Every interactive element downstream reads from that variable — buttons, borders, hover states, focus rings, the ServiceNav highlight, the sidebar accent, the product card call-to-action, the checkout wizard progress indicator, the confirmation page checkmark. One variable propagates through the entire component tree. The ServiceIntakeForm renders different fields per service. The audio form asks for genre and track count. The software form asks for project type and timeline. The accessibility form asks about the platform and compliance target. But the form component itself is one file — ServiceIntakeForm.tsx. It accepts a service key and a fields array. The fields array is a configuration object defined on each service page. Each field has a name, label, type, required flag, placeholder, and optional select options. The component maps over the array and renders inputs, selects, or textareas based on the type. Five services, five configurations, one form component. The same pattern runs through the product cards, the sidebar, the checkout flow. One set of components, five colour themes, five field configurations. The service pages are not five separate implementations. They are five datasets rendered through one shared system.