How to Build a Website for Someone Else

Overview

Learning how to build a website for someone else starts with planning the project, agreeing requirements, choosing the right tools, and delivering a maintainable final site. This guide covers practical steps you can follow to plan, design, code, deploy, test, and hand off a website to a client or stakeholder.

What you’ll learn and

why it matters:

you will learn client intake, scope definition, wireframing, front end development with HTML/CSS/JavaScript, version control, hosting options, deployment automation, testing, and handoff documentation. These steps reduce scope creep, speed development, and make maintenance predictable.

js for build tools. Time estimate: plan for one to four weeks depending on complexity. Total hands-on time for a simple brochure site: ~6-20 hours.

For an e-commerce or custom app expect several weeks.

Step 1:

Plan the website (how to build a website for someone else)

Action to take: run a discovery meeting and produce a one-page project brief listing goals, audience, pages, content sources, deadlines, and the acceptance criteria.

Why you are doing it: a brief prevents misunderstandings, establishes scope, and gives you the checklist you will build against.

Checklist:

1. Ask client about goals, users, and success metrics.
2. Define required pages and features (contact form, blog, store).
3. Agree on branding assets and content delivery timeline.
4. Create acceptance criteria for each page.

md and add to repo.

Expected outcome: a signed or acknowledged one-page brief and an entry in your issue tracker with tasks.

Common issues and fixes:

• Issue: scope creep after start. Fix: refer to the signed brief and create a change request process.
• Issue: missing content. Fix: set deadlines for content and offer to create stub content.

Time estimate: ⏱️ ~60 minutes

Step 2:

Set up the development environment and repository

Action to take: create a git repository, set branch rules, and configure a basic project skeleton.

Why you are doing it: version control and a consistent environment let you track changes, collaborate, and roll back mistakes.

Checklist:

1. Create a new repo on GitHub or GitLab.
2. Clone locally and create main and develop branches.
3. Add README, license, .gitignore, and basic folder structure.

Commands and examples:

git clone git@github.com:your-org/client-project.git
cd client-project
git checkout -b develop
mkdir src public
echo "# Client Project" > README.md
git add .
git commit -m "initial project skeleton"
git push -u origin develop

Expected outcome: a remote repository with an initial branch and project skeleton ready for code.

Common issues and fixes:

• Issue: SSH access problems. Fix: use HTTPS clone URL or add your SSH key to GitHub settings.
• Issue: accidentally committing secrets. Fix: add secrets to .gitignore and rotate exposed keys.

Time estimate: ⏱️ ~20 minutes

Step 3:

Design and wireframe

Action to take: create wireframes and a simple visual design or pick a template if budget or timeline is tight.

Why you are doing it: visual direction ensures the client and you agree on layout, hierarchy, and content placement before coding.

Checklist:

1. Build low-fidelity wireframes for each page.
2. Create a simple style guide: colors, fonts, spacing rules.
3. Present designs and collect sign-off.

Tools and examples: use Figma, Adobe XD, or pen-and-paper photographed and uploaded. For simple projects, pick a responsive HTML/CSS starter like Bootstrap or Tailwind.

Expected outcome: approved wireframes and a small style guide you can reference during development.

Common issues and fixes:

• Issue: client wants many revisions. Fix: limit rounds (for example 2 rounds included) and document additional work as paid extras.
• Issue: accessibility not considered. Fix: include basic accessibility checks in design review (contrast, font sizes, keyboard navigation).

Time estimate: ⏱️ ~2-6 hours

Step 4:

Build the frontend with HTML CSS and JavaScript

Action to take: implement pages using semantic HTML, modular CSS, and minimal JavaScript. Start from your approved wireframes.

Why you are doing it: clean, semantic code is easier to maintain, accessible, and performs better.

Checklist:

1. Create index.html and page templates in the src folder.
2. Implement CSS using a preprocessor or utility framework if chosen.
3. Add lightweight JS for interactive elements.

Example basic HTML template:

<!doctype html>
<html lang="en">
<head>
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width,initial-scale=1">
 <title>Client Site</title>
 <link rel="stylesheet" href="/styles.css">
</head>
<body>
 <header><h1>Client Brand</h1></header>
 <main><section id="home">Welcome text here</section></main>
 <footer>&copy; 2026 Client</footer>
 <script src="/app.js"></script>
</body>
</html>

Expected outcome: functioning static pages that match the approved design on desktop and mobile.

Common issues and fixes:

• Issue: layout breaks on small screens. Fix: use responsive units, media queries, and test with browser dev tools.
• Issue: slow page load. Fix: optimize images, defer noncritical JS, and minify CSS.

Time estimate: ⏱️ ~3-8 hours

Step 5:

Add forms, CMS, and dynamic features

Action to take: implement contact forms, a CMS for content editors, or simple dynamic features.

Why you are doing it: clients need to update content without code. Selecting the right level of dynamic functionality balances cost and maintainability.

Checklist:

1. If simple site, add a form that posts to Formspree or Netlify Forms.
2. For editable content, choose a CMS: WordPress, Netlify CMS, Sanity, or a headless CMS.
3. If e-commerce required, consider Shopify, WooCommerce, or Snipcart.

Commands and examples for a static form using Netlify forms:

1. Add a form element with the data-netlify attribute to your HTML.
2. Deploy to Netlify and enable form handling in the Netlify dashboard.

Expected outcome: functioning contact form and a content editor workflow for the client.

Common issues and fixes:

• Issue: form spam. Fix: implement honeypot fields or reCAPTCHA.
• Issue: CMS complexity overwhelms client. Fix: provide tailored training and preconfigure common tasks.

Time estimate: ⏱️ ~30-90 minutes

Step 6:

Host, deploy, and automate with CI/CD

Action to take: choose hosting, configure DNS, and set up continuous deployment from your repository.

Why you are doing it: automated deploys reduce manual errors and let changes go live after passing tests.

Checklist:

1. Pick hosting: Netlify or Vercel for static sites, DigitalOcean or AWS for servers.
2. Connect repo to hosting and configure build command.
3. Set up a simple CI pipeline to run linting and tests.

Commands and examples for a basic CI deploy using GitHub Actions (minimal):

Expected outcome: code pushed to main automatically builds and deploys to production.

Common issues and fixes:

• Issue: DNS not propagating. Fix: verify nameservers, clear DNS cache, and wait up to 48 hours.
• Issue: build fails on CI but works locally. Fix: match Node and package versions, add .nvmrc or engine specs.

Time estimate: ⏱️ ~30-90 minutes

Step 7:

Handover, documentation, and maintenance plan

Action to take: prepare handoff documents, training, and a basic maintenance schedule.

Why you are doing it: a formal handoff reduces support requests and clarifies responsibilities for updates, backups, and security.

Checklist:

1. Create a Handoff.md with repo links, login info stored in a password manager, and deployment steps.
2. Record a short screencast demonstrating site updates and content editing.
3. Propose a maintenance plan: frequency of backups, plugin updates, and monitoring.

Expected outcome: the client has clear documentation and can request ongoing support or take control.

Common issues and fixes:

• Issue: client loses credentials. Fix: store credentials in a shared password manager like 1Password and include recovery contact.
• Issue: client accidentally breaks content. Fix: enable easy rollbacks via git and keep backups.

Time estimate: ⏱️ ~60 minutes

Testing and Validation

How to verify it works with checklist:

1. Cross-browser check: test in Chrome, Firefox, Edge, and Safari using BrowserStack or local machines.
2. Mobile responsiveness: verify breakpoints in browser dev tools and on real devices if possible.
3. Accessibility: run axe or Lighthouse audits and fix critical issues like contrast and missing alt text.
4. Performance: run Lighthouse and aim for <2s Largest Contentful Paint on good connections.
5. Forms and integrations: submit test form entries, check email delivery, and test CMS save/publish workflows.

Use these checks before final client review and sign-off. Each test should be recorded and any failing items added to your issue tracker for resolution.

Common Mistakes

1. Skipping the discovery phase: without clear requirements you will waste time building the wrong thing. Always get written agreement.
2. Ignoring backups and staging: deploying directly to production increases risk. Use staging and automated backups.
3. Overcomplicating the CMS: giving clients a complex CMS leads to support calls. Choose simple, tailored editors or provide training.
4. Not testing on real devices: emulators are useful but do real-device checks for touch and performance differences.

Avoid these pitfalls by following the planning checklist, automating deploys and backups, and including client training in your process.

FAQ

How Long Does It Take to Build a Simple Client Website?

A simple brochure site typically takes 6 to 20 hours spread over a few days for a single developer. Time varies based on content readiness, revisions, and integrations.

Which Hosting Option Should I Pick for a Small Business Site?

For static brochure sites use Netlify or Vercel for fast deployment and built-in CDN. For dynamic apps or e-commerce consider managed services like Shopify or a VPS if you need custom server logic.

How Do I Make the Site Editable by the Client?

Use a headless CMS, WordPress, or a lightweight CMS like Netlify CMS depending on the project. Provide clear documentation and a short training session to the client.

What Should I Include in the Handoff Documentation?

Include repo links, build and deploy steps, credentials stored securely, content editing steps, backup schedule, and contact info for support. Add screenshots or a short video for tasks the client will perform.

How Do I Price a Website for Someone Else?

Estimate hours for discovery, design, development, testing, and handoff, then add a margin for revisions and unexpected work. Consider fixed-price for predictable scopes and hourly for open-ended projects.

How Do I Handle Scope Changes After Starting?

Create a change request process: document the new request, estimate hours, and get client approval before implementation. Keep a signed contract that outlines the process for changes.

Next Steps

After completing the initial site and handoff, track performance and user feedback for two to four weeks. Schedule the first maintenance check within 30 days to apply updates and review analytics. Offer a monthly or quarterly support plan to handle updates, backups, and small enhancements, and prepare a roadmap for larger future features.

Further Reading

• How to Start a Website Design Company - Complete Guide
• How to Start a Website Making Business Guide
• Steps to Launch a Website Today
• How to Build a Website for Small Business Practical Guide