How do you plan a good website?

A fast builder does not remove the need for decisions. It makes unclear decisions visible sooner. If the brief is only “make me a nice website,” your Hand still has to guess the audience, hierarchy, offer, proof, navigation, page count and conversion path. You will spend the saved build time correcting assumptions.

Answer these questions before you draw the sitemap

You do not need a fifty-page strategy deck. A useful website brief can start with ten direct answers. Write them yourself or ask ChatGPT to interview you one question at a time.

1. Who is the primary audience?Pick the person whose decision matters most instead of trying to write for everyone at once.
2. What situation brings that person to the website?Are they comparing providers, solving an urgent problem, researching a category or already close to buying?
3. What problem, desire or goal do they have?Describe the change they want in their own language, not your internal product terminology.
4. What exactly are you offering?A service, product, software subscription, consultation, booking, quote, resource or something else?
5. Why choose you instead of an alternative?Use a real difference: expertise, process, speed, specialization, product capability, price model or proof.
6. What is the primary action?Book a call, request a quote, start free, buy, subscribe or contact you. A website becomes clearer when one action wins.
7. What makes the promise believable?Results, cases, reviews, customer names, certifications, experience, product screenshots or concrete numbers.
8. What could stop someone from acting?Price, risk, time, migration effort, trust, complexity or uncertainty about what happens next.
9. How will people arrive?Search, ads, social, referrals, campaigns, a sales conversation or an existing customer relationship all create different expectations.
10. What must a visitor know before they can decide?This answer becomes your shortlist of pages, sections, proof and FAQs.

If one of those answers is vague, that is a good place to use ChatGPT before you ask your Hand to write code. Ask it to challenge the answer, spot overlaps and turn internal language into something a visitor can understand.

One page or multiple pages?

This is one of the first structural choices worth making explicitly. A one-pager is not “simpler by default” and a multi-page site is not automatically “more professional.” Choose the format that matches the number of different questions visitors need answered.

Build the homepage as a route from question to action

The homepage does not need every section below. Treat this as a menu of jobs the page may need to do. The order works well for many service businesses, consultants and software products because it moves from orientation to trust to action.

1. Hero. State what you offer, who it is for and the primary CTA.
2. Problem and recognition. Show that you understand the situation that brought the visitor here.
3. Your solution. Explain what you actually do in plain language.
4. Benefits and outcomes. Translate features into the change the customer gets.
5. Offer or services. Show the options a visitor can choose from.
6. How it works. Reduce uncertainty with a short process: for example discover → plan → deliver → improve.
7. Proof. Use cases, customer quotes, logos, screenshots, results or numbers that support the promise.
8. About you or the team. Add context when the person behind the work matters to the decision.
9. FAQ. Answer the objections that would otherwise stop somebody just before the CTA.
10. Final CTA. Repeat the next step once the visitor has enough context to act.

The point is not to force every company into the same template. The point is to give each section a job. If a section cannot answer a visitor question or support the decision, you probably do not need it.

Choose supporting pages based on real information needs

Once the homepage story is clear, decide what deserves depth of its own. A business website often grows into some combination of these pages:

• Home. The overview and primary conversion route.
• Service or product pages. One page for each materially different offer, solution or product category.
• About. Vision, experience, team and the context behind the company.
• Cases or results. Concrete examples of work, outcomes and customer proof.
• Resources or knowledge. Useful answers that build authority and help people discover you.
• Contact. A low-friction way to contact, book, request a quote or find practical details.
• FAQ. A separate page when questions are too important or numerous for the homepage.
• Legal pages where applicable. Privacy, cookies and terms depend on what your business and website actually do.

For search engines and answer systems, separate pages can also help when the topics genuinely serve different intents. If “website development,” “AI automation” and “process improvement” are distinct offers, separate landing pages can make it easier for both people and machines to understand when each page is relevant. Do not create thin pages just to multiply keywords; split content because the answer itself is different.

Use component libraries for inspiration after the structure is clear

Once you know the hierarchy, you can look for visual and interaction patterns. Two useful places to browse are Watermelon UI ↗ and shadcn/ui ↗.

Turn your answers into a build brief

You can do this as a conversation with ChatGPT before any code is written. Paste a rough version of the template below and let it ask follow-up questions where your answers are still weak.

Act as my website strategist before we write any code.

Business / project:
Primary audience:
Situation that brings them to the site:
Main problem or desired outcome:
Offer:
Why choose us:
Primary CTA:
Proof we can show:
Main objections:
Likely traffic sources:
Content we already have:
Design references I like and why:

First, challenge anything that is vague or contradictory.
Then recommend whether this should be a one-page or multi-page site and explain why.

After I approve that decision, produce:
1. A one-sentence positioning statement
2. A sitemap
3. A homepage section outline
4. The purpose and CTA of every page
5. The proof and FAQ content we still need
6. A visual/component direction in plain language
7. An acceptance checklist for the finished site

Do not start writing code until the brief is approved.

A good brief makes the build task much smaller. Your Hand no longer has to invent the strategy while also implementing the site. It can focus on turning an approved structure into semantic pages, responsive components and a working deployment.

Then hand the approved plan to GitHub + Cloudflare

Once the strategy, sitemap and content hierarchy are approved, the technical handoff becomes the easy part: put the source in GitHub, use Cloudflare as the publishing layer, and keep both connected to the Hand that will maintain the site. If you need the infrastructure details, the companion guide What do you really need to host a website? explains the minimal stack and when Firecrawl, Resend or Supabase become useful.

The end goal is not a site with the most sections, pages or effects. It is a site where the right visitor can quickly understand the offer, believe it and take the next step — and where your Hand has a clear enough brief to keep improving that route later.