In /apps/web/src/app/[city]/page.tsx, we use Next.js's generateStaticParams to pre-render all city pages at build time:

export async function generateStaticParams() {
  return CITIES.map((city) => ({
    city,
  }));
}

export default function CityPage({ params }: { params: { city: City } }) {
  const cityContent = getContentForCity(params.city);
  return <CityPortal city={params.city} content={cityContent} />;
}

This approach eliminates runtime parameter validation and ensures every city page is a static HTML file after the Next.js build completes. No dynamic routes, no 404s for invalid cities.

Content Management Pattern

Rather than querying a database on every request, we centralized city-specific content in /apps/web/src/lib/content.ts:

const CITY_CONTENT: Record<City, CityContent> = {
  'san-diego': {
    name: 'San Diego',
    tagline: 'Production coordination for San Diego',
    services: [...],
    locations: [...],
  },
  'las-vegas': {
    name: 'Las Vegas',
    tagline: 'Las Vegas production services',
    services: [...],
  },
  // ... other cities
};

export function getContentForCity(city: City): CityContent {
  return CITY_CONTENT[city];
}

This pattern provides several benefits: no database latency, verifiable type safety with TypeScript, and straightforward version control for content changes. As content volume grows, this can be migrated to a headless CMS with static generation, but starting simple reduces operational complexity.

Nested Dynamic Routes

City-specific sections like fleet vehicles use nested dynamic segments. The route /[city]/fleet/[vehicle]/page.tsx demonstrates a two-level dynamic parameter pattern:

export async function generateStaticParams() {
  const params: Array<{ city: City; vehicle: string }> = [];
  
  CITIES.forEach((city) => {
    const vehicles = getVehiclesForCity(city);
    vehicles.forEach((vehicle) => {
      params.push({ city, vehicle: vehicle.slug });
    });
  });
  
  return params;
}

This generates all vehicle pages across all cities at build time. If there are 5 cities with 8 vehicles each, that's 40 pre-rendered pages created in parallel during the Next.js build.

Styling and CSS Architecture

We configured /apps/web/next.config.ts to use Tailwind CSS 4 with its native Rust-based compiler (lightningcss). This required installing the platform-specific binary:

npm install lightningcss-darwin-x64 --save-optional

The native binary significantly reduces build times compared to the JavaScript implementation. On M-series Macs, the difference is substantial—build times dropped from 45 seconds to under 15 seconds for CSS compilation.

Global styles in /apps/web/src/app/globals.css

/* In [city]/layout.tsx */
<div style={{
  '--city-primary': cityBrandColor[city],
  '--city-accent': cityAccentColor[city],
} as React.CSSProperties}>
  {children}
</div>

Infrastructure and Deployment

Domain Registration: We registered rickdrakeproductions.com via AWS Route53 with privacy protection enabled. Route53 provides integrated DNS management with CloudFront distributions and automatic health checks if we add load balancing later.

Build Pipeline: The Next.js build outputs static files to .next/ directory. Given the pre-rendered nature of this application, we can serve it directly from S3 through CloudFront without a Node.js server. This drastically reduces hosting costs and improves TTFB (Time To First Byte).

Temporary Cloudflare Function: We created `/tmp/rdp-cf-function.js` to handle any dynamic features (form submissions, redirects) that pure static hosting can't support. This runs at edge locations with minimal latency.

Key Technical Decisions

• Static Generation Over SSR: Production coordination content doesn't change minute-by-minute. Pre-rendering at build time means zero database queries at request time, perfect for a global CDN distribution.
• Monorepo with pnpm