min23a/personal-web

1. This repository is a Next.js application built as a content-heavy personal/agency site rather than a generic app. The architecture centers on route-driven pages, reusable UI sections, and data modules that feed static and dynamic-looking marketing pages.

2. The main boundary is the pages/ directory. It defines the public site routes: home, about, contact, privacy policy, shopify developer pages, freelance/shopify hire pages, blog index and blog detail routes, project index and project detail routes, plus a country-based landing-page route under shopify-developer-in/[...country].js.

3. Dynamic content is handled through catch-all routes:

- pages/blogs/[...slug].js for individual blog articles

- pages/projects/[...id].js for project detail pages

- pages/shopify-developer-in/[...country].js for location-specific service pages

These routes indicate a content model driven by slugs and page metadata rather than a database-first product model.

4. The Data/ folder is the content layer. It contains structured page and catalog data such as blogs, projects, menu items, SEO maps, location pages, authority pages, reviews, personal profile data, and hiring details. The pages and components likely read from these modules to render consistent marketing copy and link structures.

5. UI is split between three component tiers:

- Components/ for page-level composition and section containers

- Components/Section/ for homepage/landing-page sections like hero, skills, projects, blog, reviews, announcements, and location-based blocks

- Snippet/ for smaller reusable primitives such as cards, navigation variants, accordions, breadcrumbs, typography, SEO helpers, and social/analytics utilities

This suggests a composition-heavy design system where pages are assembled from reusable content blocks.

6. The homepage and landing pages are built from section blocks rather than a single monolithic template. Files like HeroSection, AboutMe, ProjectsSec, BlogSec, UpworkReviews, Skills, and Ending show that the site is organized as a sequence of marketing sections with data-fed content.

7. Navigation and layout are centralized. Components/Layout.js, Components/Navigation.js, Components/Footer.js, and mobile/desktop nav snippets indicate a shared shell around all pages, with responsive navigation behavior separated into reusable variants.

8. SEO and structured data are first-class concerns. There are dedicated files for JsonLd, SEO, blogSchema, SeoSchema, seoMap, and next-sitemap.config.js. This points to a site designed for search discoverability, with page-specific metadata and schema generation as a core cross-cutting layer.

9. Analytics, cookie consent, and legal/privacy concerns are also isolated. CookieConsent, Snippet/consent.js, and Snippet/Ganalytics.js suggest tracking is gated by consent. pages/privacy-policy.js and Data/PrivacyPolicy.js provide the legal content backing that flow.

10. The only explicit backend surface is pages/api/. contact.js likely handles form submissions, and hello.js is the default example endpoint. The presence of Snippet/mongodb.js suggests the contact flow may persist or forward data through MongoDB, making contact the main transactional path in an otherwise mostly static site.

11. External data integration appears lightweight. services/git.js and the pages/git.js route imply an API-backed or fetch-based Git/project showcase, while Data/upworkReviews.js and the Upwork review components indicate curated third-party testimonials rendered from local data rather than live integration.

12. Styling and interaction are handled with Tailwind and global CSS. tailwind.config.js, postcss.config.js, styles/globals.css, and styles/scroll-animate.css support a utility-first UI with a small amount of custom animation behavior, reinforced by services/scroll-animate.js.

13. Static assets are mostly local and presentation-oriented. public/ contains a PDF resume, Images/ holds blog imagery, and logo/ appears to store brand assets. This reinforces that the site is optimized for fast content delivery with minimal runtime dependencies.

14. For an architecture diagram, the cleanest high-level flow is: route page in pages/ → shared layout/navigation → section/snippet components → content pulled from Data/ and static assets → optional API route for contact → SEO/consent/analytics applied cross-cutting across the rendered page.