Building Your First Website: The Prompt, the Questions, and How to Answer Them

This picks up exactly where How to Build and Deploy Any Website to a Hostinger VPS Server leaves off. If you've finished Parts A through D — Node and Git installed, a GitHub account, a Hostinger VPS with Docker and Traefik running, and a scaffolded project with a working deploy.sh — you have an empty, unstyled starter page sitting on a live URL. This is the part where it actually becomes your website.

There's no special syntax for this. You just talk to Claude Code the same way you would brief a designer, and it asks you the same questions a designer would ask on a first call.

The opening prompt

Don't try to describe a finished website in one paragraph. Give Claude the facts about the business and let it propose a direction — that's what it's good at. A solid opening prompt has four parts: what the business is, who it's for, what pages/actions matter most, and how much creative freedom you're handing over.

"I'm building a website for [business name], a [type of business] in [city/area]. Our customers are mainly [who]. The main thing we want visitors to do is [call, book, buy, fill out a form, browse a menu — whatever the one goal is].

Before you write any code, ask me about visual style, colors, and what pages/sections we need. Then propose a homepage layout and a color/font direction before building it out."

That last line matters. Asking Claude to check in before building means you get a plan and a couple of questions back — not 400 lines of code you have to unwind because it guessed wrong about the vibe.

The questions Claude Code will usually ask

Expect some version of these, in no particular order:

• Style and mood — a handful of adjectives it wants from you: modern, minimal, warm, bold, playful, corporate, rustic, luxury, industrial.
• Color preference — do you have brand colors already (from a logo, a sign, a business card), or is this a blank slate?
• Fonts — clean and geometric vs. something with more personality, and whether headings and body text should contrast or match.
• Pages/sections needed — home, about, services, menu, pricing, gallery, contact, blog. It'll usually propose a shortlist based on your industry rather than making you list every page from scratch.
• Functionality — a contact form, online booking, a menu or product catalog, a photo gallery, testimonials, a blog, e-commerce checkout, a map/location embed.
• Content — do you have real copy and photos ready, or should it draft realistic placeholder text and use stock-style placeholders you'll swap later?
• Reference sites — any site you've seen (yours or a competitor's) whose feel you want to borrow, even loosely.

How to answer well

You don't need design vocabulary. A few concrete things beat one vague instruction:

• "You choose" is a valid answer — Claude will make a reasonable, cohesive choice. Use this for anything you genuinely don't care about, so you can spend your input on what you do care about (usually: the colors, and the one action you want visitors to take).
• Two or three adjectives beat a mood board you don't have — "warm, a little rustic, not corporate" is enough to steer fonts and color temperature.
• If you have a logo or existing signage, share the colors from it. Consistency with what customers already recognize matters more than any trend.
• Don't describe pixels — ask for options. Instead of trying to specify a layout in words, ask: "Build the homepage two ways — one with a big photo hero, one with a simpler text-led hero — and let me look at both before we pick." Comparing two real screenshots is faster and more accurate than describing a preference.
• Say what the site must never do, if anything — e.g. "no autoplaying video," "no pop-ups," "keep it to one page for now." Constraints are as useful as preferences.

Style and functionality by industry

Use this as a starting point when Claude asks, not a rulebook. Naming the industry alone gets you 80% of the way there — Claude already has a sense of what a plumber's site and a boutique law firm's site should each look like. These are just concrete starting answers if you want to skip the back-and-forth.

Example of naming both at once, which is usually all it takes:

"It's a family-run electrical contracting business — go bold and trustworthy, not corporate. Big click-to-call button above the fold, a service area map, and a simple quote-request form. We don't need e-commerce or a blog."

From dev, through git, to production

Once you and Claude land on a direction, the loop is the same one described in Part F of the setup guide — repeated for as many rounds of changes as it takes:

1. Build and preview locally. Claude runs the dev server, makes the change, and should hand you a localhost URL (or a live preview) to look at before anything is considered done.
2. Review like a client would. Check it on both desktop and a phone- sized window. Say what's off in plain language — "the hero text is too small on mobile," "I don't like that color for the button" — Claude doesn't need precise CSS terms.
3. Commit on a branch, not straight to main. Ask Claude to commit the change and open a pull request rather than pushing directly, so you always have a clean point to roll back to if a round of changes goes sideways.
4. Merge when you're happy. Once the PR looks right, merge it.
5. Deploy with ./deploy.sh. This pushes to GitHub, pulls onto the VPS, and rebuilds the container — see the Deploy & DNS Prompt Cheatsheet if you haven't set this script up yet.
6. Check the live URL, not just the local one, before calling a change done — the local preview and the deployed container are two different things, and only one of them is what customers see.

Repeat that loop a page at a time. Most first sites go: homepage → one or two key inner pages (services/menu/pricing) → contact/booking → a pass on mobile → real content swapped in for placeholders → go live for real.

Quick checklist

• Told Claude the business, audience, and the one action you want visitors to take
• Asked Claude to propose style/layout before building, not after
• Gave 2–3 style adjectives, or existing brand colors, or both
• Compared at least two real options for the homepage hero instead of describing one in words
• Picked functionality from the industry table (or told Claude to choose) rather than leaving it unscoped
• Reviewed every change on a localhost preview before merging
• Deployed with ./deploy.sh and checked the live URL, not just the local one