# Southern Masonry Supply Next.js Rebuild Plan ## Summary Build a production-ready Next.js site in TypeScript with App Router, using the provided screenshots as structural inspiration, info.md as content source, and public/images as the visual asset base. The v1 will ship as a 5-page marketing/catalog site with strong local SEO, reusable content-driven sections, a placeholder-ready contact API, and Dockerized local/dev deployment so npm run dev works immediately. ## Key Changes - Initialize a new Next.js App Router project in TypeScript with a clean component/content structure, responsive layout system, shared header/footer, global theme tokens, and SEO-safe metadata defaults. - Create these routes with preserved slugs: - / - /about - /masonry-supplies - /landscaping-supplies - /contact - Implement a strong local-business visual direction rather than a generic template: - warm stone/terracotta/sand palette - editorial serif display + refined body font - real masonry/landscaping imagery from public/images - clear quote-first CTA treatment - Model content in static TypeScript data modules for v1: - siteConfig for business identity, address, phone, hours, socials, CTAs - materials dataset for masonry and landscaping items with category, subcategory, image, description, purchase unit, tags, featured flag - page-specific hero, trust, delivery, and FAQ content - Home page behavior: - local SEO hero with Corpus Christi positioning - split entry cards for masonry vs landscaping - trust/value section - featured materials - delivery minimums and service summary - direct links into contact/quote flow - About page behavior: - family-owned story and 30+ year credibility - mission/service philosophy - sourcing and expertise differentiators - no invented team bios or fake history beyond info.md - Supplies pages behavior: - hero/banner - filterable client-side product grid by subcategory/tags - quote CTA on every card - delivery/purchase-unit notes surfaced in-page - breadcrumb support and internal links between supply pages and contact - Contact page behavior: - business info, hours, address, phone, social links - delivery rules from info.md - contact form with client validation and a Next.js API placeholder endpoint returning structured success/error responses - map section as external Google Maps link/embed placeholder, not a hard dependency - SEO and schema: - route-level metadata, titles, descriptions, canonical defaults, Open Graph/Twitter cards - JSON-LD for LocalBusiness/Organization, WebSite, and BreadcrumbList - semantic headings, accessible nav, internal linking, crawl-friendly page structure - Delivery/runtime assets: - Dockerfile for containerized app build/run - docker-compose.yml for local container startup - .dockerignore - README updates with npm install, npm run dev, docker compose up instructions ## Public Interfaces and Data Contracts - Route contract: - /contact submits to /api/contact - Contact API response contract: - success: { success: true, message: string } - validation/server error: { success: false, message: string, fieldErrors?: Record } - Material data contract: - slug - name - category - subcategory - image - description - purchaseUnit - availabilityNote? - featured - tags - Shared config contract: - business name, tagline, NAP, hours, socials, delivery notes, nav items, footer groups, default SEO fields ## Test Plan - Verify header nav, footer links, breadcrumbs, and CTA flows between pages. - Verify /api/contact handles valid submission, missing required fields, and invalid email/phone formats. - Verify metadata and JSON-LD render per page and match visible content. - Verify images load through Next.js without layout shift regressions. - Verify Docker build succeeds and docker compose up serves the app successfully. - Preserve the existing English content direction from info.md, even though the planning conversation is in German. - Keep the classic page slugs: /about, /masonry-supplies, /landscaping-supplies, /contact. - Contact form will be implementation-ready but not wired to real email delivery yet; the placeholder API is the accepted v1 behavior. - No cart, checkout, pricing engine, CMS, or live inventory in v1. - Only provided assets in public/images are used unless implementation reveals a missing critical visual, in which case the design falls back to text-first sections rather than invented media.