TSW.ai - The Student World AI Landing Page in Nuxt 3

Summary

• Delivery: a static marketing landing page for The Student World AI (TSW.ai) featuring Hero, Features, and a Chat CTA, plus a minimal UI kit to standardize layout and buttons.
• How I unlocked speed: organized the UI into reusable sections and components (layout + UI) to iterate on design/copy without losing consistency.
• Practical effect: a lightweight, backend-free page focused on conversion (CTA) and ready for static hosting.

In ~10 days, I delivered most of the landing’s frontend work (14 commits, ~82% of the repo in the extracted slice), prioritizing visual consistency and fast turnaround.

Context

• Product and users: a marketing site to present TSW.ai and route users to the main app via CTA.
• Why it mattered: it needed to be simple, stable, and quick to publish/update (copy and visuals) to support acquisition.
• Architecture choice: intentionally static scope (SSR disabled) to reduce operational complexity in the short term.

Key Challenges

• Turning “just a landing page” into a clean, maintainable structure (sections/components/styles) without overengineering.
• Ensuring visual consistency (typography, buttons, spacing) with Tailwind and global styles.
• Keeping it stateless: no API integrations, only links/CTAs and predictable performance.

What I did

• Main page and sections: implemented the core structure and key sections (Hero, Features, Chat/CTA).
• Componentization for rapid iteration: built reusable UI/layout components to speed up copy/design changes without visual regressions.
• External links and navigation: wired CTAs and ecosystem links (main app, company site, social channels) consistently.
• Project setup: Nuxt 3 + Tailwind + pnpm with static build output (SSR disabled).

Decisions & Trade-offs

• Static site (SSR off) > SSR: simplest path for an acquisition landing page (lower complexity, more predictable deploy).
  Trade-off: gives up some SSR-specific SEO/render strategies, but the scope didn’t require them at the time.
• Small reusable components > monolithic page: sections + a minimal UI kit to keep speed and consistency.
  Trade-off: more structure/files, but less rework and easier maintenance.
• Script-based deploy (team) > CI pipeline: static publishing to S3/CloudFront via a scripted process.
  Trade-off: works, but relies on manual execution and local credentials.

Results

• Measured (engineering): 14 commits (~82% of the repo in the slice), 7 active days, ~10-day delivery (Apr 25, 2025 → May 5, 2025).
• Concrete technical proxies:
  • Landing page with three main sections (Hero, Features, Chat/CTA).
  • Minimal UI/layout kit for consistent buttons, modals, and structure.
  • CTA/link integration to the main app and ecosystem channels.
• Operational impact: a backend-free foundation for fast copy/visual iteration, ready for static AWS hosting (via the team’s process).

Note: no automated tests or observability were configured in the analyzed slice.

What I’d do differently

• Add minimal UI tests for critical components (Header/Footer/Modal/CTA) to reduce visual regressions.
• Move manual deploy to CI (e.g., GitHub Actions) with preview/staging and automated invalidation.
• Lightweight observability: CTA events and error tracking to measure conversion and catch issues early.