Project Structure · Docs

NA-AI LandingStructure

Understand the architecture before rewriting the UILink to section

NA-AI Landing is organized around a simple separation:

Data controls content. Sections render product blocks. Layout components frame the page. PyColors UI provides primitives.

This keeps customization clean, predictable, and easier to maintain as the landing page evolves.

Most product content can be updated from:

src/@data

before touching the visual implementation.

The structure is optimized for fast iteration.

NA-AI Landing separates content, sections, layout, and UI primitives so you can customize positioning and branding without rebuilding the foundation.

Customization guide

One-time payment · Instant access after purchase

Key idea

The template is designed so product content can evolve without constantly rewriting the visual foundation.

Architecture overviewLink to section

Data-driven structure

Content, pricing, navigation, FAQ, testimonials, and CTA copy live in centralized data files.

Composable sections

Landing page blocks are isolated into reusable presentational sections.

Shared UI primitives

The visual layer is powered by PyColors UI and semantic design tokens.

Fast customization workflow

The architecture prioritizes quick branding, positioning, and product iteration.

StructureLink to section

contact.ts

cta.ts

customers.ts

faq.ts

features.ts

footer.ts

hero.ts

index.ts

integrations.ts

navbar.ts

not-found.ts

pricing-table.ts

pricing.ts

globals.css

layout.tsx

page.tsx

not-found.tsx

robots.ts

sitemap.ts

manifest.webmanifest

Architecture flowLink to section

architecture-flow.txt

src/@data
  ↓
components/sections
  ↓
components/layout
  ↓
@pycolors/ui + @pycolors/tokens

Data layer

The data layer owns structured content, pricing values, navigation labels, FAQ items, testimonials, and section configuration.

Content ownershipPricing configurationNavigation structureFAQ and testimonials

Data directoryLink to section

File	Responsibility
`hero.ts`	Hero copy, CTA, badges, and visual content
`features.ts`	AI analytics feature cards and section content
`integrations.ts`	Integration categories and integration cards
`pricing.ts`	Pricing plans and billing toggle content
`pricing-table.ts`	Pricing comparison rows
`customers.ts`	Testimonials and customer proof
`faq.ts`	FAQ content
`contact.ts`	Contact form copy and goal options
`cta.ts`	Final conversion section
`navbar.ts`	Navigation links
`footer.ts`	Footer links and footer copy

Customization rule

Change data first. Edit section components only when the current structure no longer supports the product story.

Add a new sectionLink to section

Create the data fileLink to section

terminal

touch src/@data/use-cases.ts

Create the section componentLink to section

terminal

touch src/components/sections/use-cases.tsx

Compose the section inside the pageLink to section

src/app/page.tsx

import { UseCasesSection } from "@/components/sections/use-cases";

export default function Page() {
  return <UseCasesSection />;
}

Recommended architecture rulesLink to section

Prefer

data-driven content
small section components
shared PyColors primitives
semantic tokens
isolated template-specific UI

Avoid

hardcoding all copy in components
putting backend logic in sections
duplicating layout wrappers
removing token imports
forking shared UI primitives unnecessarily

Why this structure scalesLink to section

As landing pages grow, problems usually come from unclear boundaries:

copy mixed with layout logic
duplicated sections
inconsistent spacing
scattered pricing values
disconnected SEO assets
uncontrolled visual overrides

This structure reduces those problems by keeping responsibilities separate from the beginning.

Scaling principle

A good landing page architecture should make iteration cheaper over time, not more fragile.

Common questionsLink to section

Next stepsLink to section

CustomizationUpdate copy, sections, branding, SEO metadata, and assets.DeploymentDeploy the landing page to production after customization.