Live in Five Prompts: Building and Hosting a Fitness Site with an AI Coding Tool

Professional websites are usually sold as expensive and slow, yet this build argues the opposite with a concrete demo: a full fitness brand site assembled from five staged prompts inside an AI coding tool. The presenter names the target React Vite stack , the static production build idea and the shared hosting destination up front, so the viewer knows the finish line before the first line of layout appears. According to vite.dev guides, that static output is exactly what cheap hosting serves best, which frames the whole workflow as layout work now and server worries never.

Choosing the plan first

Choosing hosting feels noisy because every provider shouts different limits at once, so the video narrows the field to one shared Pro option with fast NVMe storage, unmetered bandwidth, free SSL and an enhanced control panel. Those details matter because the finished site will be plain files, not a running server, and the plan only needs to serve them quickly with room to grow. This segment leans on hosting.com plan pages, and the honest reading is that hosting.com suits static uploads well, though the discount code on screen means the recommendation is not fully independent.

The foundation prompt does the highest-leverage work: it asks for a React Vite TypeScript project with Tailwind, a base path of slash for the control panel, a component structure, a navigation bar with smooth-scroll links and a full-screen hero in cream, warm charcoal and gold. Only navigation plus hero are built at this stage, with a dark placeholder where photography will later sit. That restraint is deliberate, because early color and type choices cascade into every later section, and fixing them early avoids redesigning five components twice.

Content sections in order

With the style locked, the second prompt adds a services row with three cards for personal training, nutrition coaching and recovery, each with a short description and a gold detail link, plus a two-column story section with a charcoal placeholder beside the studio narrative. The components land below the hero without touching earlier work, and the page suddenly answers the two questions visitors ask first: what is offered and who is behind it. Keeping the same spacing and type here is what makes the growth feel designed rather than stacked.

Social proof comes next because persuasion needs evidence, not more adjectives. The third prompt adds three testimonial cards with quote, name and outcome, then a six-tile gallery that still uses charcoal placeholders at this point. The presenter checks readability, crowding and grid rhythm rather than filling pictures early, which is the right order: once layout breathes with empty boxes, it will also breathe with real photography. The page now balances text-heavy and visual zones.

Forms and metadata turn interest into contact and findability. The fourth prompt adds a centered contact section with name, email, phone and message fields plus a matching submit button, and updates index.html with title, description, Open Graph tags and a provisional canonical link. The form only keeps values in React state, so nothing is actually delivered, a limit worth stating plainly. Search engines and social networks read that head section first, and the ogp.me specification explains why those four social tags decide how link previews look when the page is shared.

Visuals and small screens decide whether the site feels finished. The fifth prompt swaps every placeholder for remote Unsplash pictures across hero, story and gallery, then tightens the whole layout for a 375-pixel viewport with a collapsing hamburger menu, stacked cards, story image above text and a two-column gallery plus a simple footer. Referencing remote Unsplash files directly keeps the project folder lean, though unsplash hotlinking guidance warns that availability and view counting depend on using proper file addresses. The mobile walkthrough then checks the usual failure points: spacing, image sizing, stacking and navigation behavior.

From source files to live domain

Development files cannot go live as they are, so the next step compiles them. The assistant runs the production build inside the same coding session, producing a dist folder with a compiled index.html plus minified hashed script and style bundles, while source files, TypeScript origins and heavy modules stay out. That cleanliness is the point: the upload stays small and the server only receives what browsers need. The vite.dev build guide describes this exact contract, where the entry file plus the assets folder form the deployable unit.

Deployment itself is refreshingly boring: log into the panel, open the FTP area and copy everything inside dist directly into the root of public_html, not the folder itself, so index.html sits where the domain expects it. No archives to unpack and no server tuning are needed for plain files, plus a small rewrite file covers single-page routing edge cases. The tailwindcss.com responsive documentation helps explain why this step rarely breaks layouts: the breakpoints already live in the classes, so the live server only needs to deliver the same bytes.

The closing inspection is what separates a demo from a delivery. The presenter opens the real domain, scrolls hero through footer, confirms fonts, colors and spacing match the local preview, clicks navigation links to verify smooth scrolling survived compilation, then repeats the pass on a phone viewport. The contact form is shown but correctly not tested for delivery, because it remains a front-end placeholder. That honest boundary, combined with verified hosting.com behavior and vite.dev output rules, leaves a reproducible path: five prompts, one build command, one upload, and a business site anyone can clone with their own content.