Hiring a web developer for the first time is stressful. You don't know what to expect, you don't know what's normal, and you don't know what you're supposed to do versus what the developer handles.
This post walks through the entire process — from your first enquiry to the day your site launches. What happens at each stage, what you'll be asked for, and what you should expect from the developer.
If you've never hired a developer before, this is the guide nobody gives you.
Stage 1 — Initial enquiry
What happens: You reach out. The developer responds.
What to expect:
- A reply within 24–48 hours (if slower, that's a red flag)
- An initial conversation to understand what you need
- A rough sense of whether they're a good fit for your project
What you do:
- Describe your project in plain English — what you want the site to do, not how it should be built
- Be honest about your budget range (hidden budgets waste everyone's time)
- Ask any questions you have about the developer's process
What you shouldn't do:
- Expect a full quote from a single email — real quotes need a real conversation
- Send a 3,000-word brief. Short descriptions work better as a starting point.
Stage 2 — Discovery and scoping
What happens: The developer asks you questions. This is where the actual project starts.
What to expect:
- A conversation (call or email) about:
- What the site is for
- Who it's for
- What pages or features are needed
- What you'd like it to look and feel like
- Any constraints (timeline, budget, existing tools)
- A written scope or proposal summarizing what's included
What you do:
- Answer questions clearly and completely
- Share any existing assets (logos, brand colors, content)
- Flag anything unusual upfront (integrations, complex features)
- Be realistic about timeline and budget
What you shouldn't do:
- Assume the developer will "figure out what you want" — that's how projects go wrong
- Forget to mention constraints — they shape everything downstream
This is the most important stage. Projects that go well are almost always projects where discovery was done properly. Projects that go badly usually skipped this part.
Stage 3 — Agreement and deposit
What happens: You both agree on scope, timeline, and price. A contract is signed. A deposit is paid.
What to expect:
- A written agreement or contract that covers:
- Scope (what's included)
- Timeline
- Payment schedule
- Number of revision rounds
- Code ownership
- Post-launch support
- An invoice for the initial deposit (usually 30–50% of the total)
What you do:
- Read the contract carefully
- Ask about anything unclear
- Pay the deposit to start the project
What you shouldn't do:
- Start work without a written agreement — this protects both sides
- Expect to pay less than 30% upfront (most developers require this)
Red flag: If a developer won't put things in writing, walk away.
Stage 4 — Content gathering
What happens: You provide everything the developer needs to build the site.
What to expect:
- The developer sends you a list of what's needed:
- Text content for each page
- Images and photos
- Logos, brand colors, fonts
- Any product data (for stores)
- Login credentials for existing tools (if applicable)
What you do:
- Provide content in an organized way (Google Docs, shared folder, etc.)
- Don't write content in a rush — good copy matters more than people think
- If you don't have images, either source them or ask the developer about stock photos
What you shouldn't do:
- Delay content — this is the #1 cause of projects going late
- Provide placeholder content with a plan to "fix it later" (it never happens)
- Assume the developer will write your copy — some will, some won't. Clarify upfront.
Reality check: If you're paying for the site to be built, you're providing the content. If you want the developer to also write content, that's a separate service and usually costs extra.
Stage 5 — Design phase
What happens: The developer creates the visual design of the site.
What to expect:
- For a template-based site: customization of an existing template to match your brand
- For a custom design: a design mockup or a live staging site you can see
- A round of revisions after you see the first version
What you do:
- Give feedback quickly and clearly
- Point at specifics — "the header is too tall" is better than "it feels off"
- Decide quickly so the project stays on track
What you shouldn't do:
- Ask for many changes over many rounds — this delays everything
- Change direction mid-project ("actually, let's do it completely differently")
- Compare to unrelated sites ("make it look like Apple's website")
How revisions work: Most developers include a specific number of revision rounds (often 2–3). Use them wisely. If you need more, that's usually an extra cost.
Stage 6 — Development
What happens: The developer builds the site. This is the longest phase and requires the least from you.
What to expect:
- The developer building pages, features, and functionality
- Occasional updates on progress
- Possibly seeing a live staging version of the site as it comes together
What you do:
- Stay available for questions — quick answers keep things moving
- Don't micromanage — let the developer work
- Be reachable in case something requires a decision
What you shouldn't do:
- Ask for daily updates (this slows things down)
- Change requirements mid-build (this resets work)
- Disappear for a week when the developer needs a decision
How long this takes: Depends on the project. Simple sites: days. Complex sites: weeks.
Stage 7 — Testing and revisions
What happens: The site is complete. You review it. You request changes.
What to expect:
- A staging link where you can view the full site
- The developer testing on multiple devices and browsers
- Your round of revisions — you request changes, they implement
What you do:
- Test the site on your phone, tablet, and computer
- Click every link, submit every form, test every interactive element
- Write down all changes and send them in one list (not dribbled out over days)
- Be specific: "the contact form doesn't send" is better than "the contact page is weird"
What you shouldn't do:
- Approve the site without actually testing it
- Ask for changes in multiple rounds when one would do
- Add new features that weren't in scope ("can we also add...")
How revisions work here: This stage is usually the last chance for major changes. After launch, everything becomes an ongoing "support" or "new work" request.
Stage 8 — Launch
What happens: The site goes live. This is often a single day of work.
What to expect:
- Final testing
- DNS configuration (pointing your domain to the new site)
- Deployment to your hosting
- Handover of credentials, files, and documentation
What you do:
- Provide any final login credentials needed
- Confirm you're ready for the site to go live
- Complete your final payment (usually the remaining 50–70%)
What you shouldn't do:
- Assume launch day is the end of the project — there's often a warranty period after
- Change your domain settings yourself during this time (this can break things)
What can go wrong: DNS changes often take a few hours to propagate worldwide. If the site seems "broken" right after launch, wait 24 hours before assuming something is wrong.
Stage 9 — Post-launch support
What happens: The site is live. You have some support from the developer.
What to expect:
- A warranty period (usually 7–30 days) covering bugs caused by the developer's work
- Documentation on how to update the site yourself (if applicable)
- An offer for ongoing maintenance, if the developer provides it
What you do:
- Test the live site
- Report any issues during the warranty period
- Decide whether to take ongoing maintenance (often worth it)
What you shouldn't do:
- Expect free changes forever — post-warranty work is usually billed
- Panic over small visual differences between staging and live (usually a cache issue)
What to expect after warranty: Any further changes are usually billed at an hourly rate or as a new project. This is normal.
What the whole process looks like
Here's the full timeline for a typical small business website:
| Stage | Typical duration |
|---|---|
| Initial enquiry | 1–3 days |
| Discovery and scoping | 2–5 days |
| Agreement and deposit | 1–3 days |
| Content gathering | 3–14 days (client-dependent) |
| Design phase | 3–7 days |
| Development | 1–3 weeks |
| Testing and revisions | 3–7 days |
| Launch | 1–2 days |
| Post-launch support | 2–4 weeks |
Total: 3–8 weeks for a typical small business website, depending on how quickly content and feedback happen.
The biggest variable is your own responsiveness. Developers are usually fast. Clients are usually the bottleneck.
Your responsibilities as a client
Here's what you're responsible for in the process:
- Content. All of it. Text, images, product data.
- Feedback. Fast, clear, specific.
- Decisions. When the developer asks, respond.
- Payments. On time, as agreed.
- Access. Provide credentials and logins when needed.
Most delays come from one of these five. If you handle them well, the project will go smoothly.
What good communication looks like
A good developer communicates proactively:
- Updates even when there's nothing exciting to say
- Warnings if they're going to miss a deadline
- Clear questions when something is unclear
- Honest answers about what's possible in your budget and timeline
A bad developer goes silent, gets defensive when asked for updates, or blames delays on everyone else.
If your developer goes quiet for more than a few days without explanation, that's a warning sign. Address it directly.
What to do if something goes wrong
Every project has moments where things don't go as planned. What matters is how they're handled.
If you're unhappy with something:
- Be specific. "The header feels wrong" is hard to fix. "The header is too tall on mobile" is fixable.
- Talk to the developer first. Most issues are miscommunications, not bad work.
- Refer to the contract. If a promise isn't being kept, point to where it was agreed.
- Escalate only if necessary. Most developers will fix genuine problems.
Problems happen on both sides. A good client and a good developer can resolve almost anything. A bad relationship on either side makes everything harder.
The bottom line
Hiring a web developer isn't mysterious once you know the process. You provide the vision and content, they build the site, you give feedback, they refine and launch.
The clients who have the smoothest experiences are the ones who:
- Communicate clearly from the start
- Provide content on time
- Give specific feedback
- Respect the developer's process
- Pay on schedule
The developers who have the smoothest experiences are the ones who:
- Communicate proactively
- Set realistic expectations
- Deliver what they promised
- Handle problems professionally
None of this is complicated. It just requires both sides to be clear, honest, and reliable.
If you're about to hire a developer and want to know what to ask beforehand, read our 10 questions to ask before hiring a web developer.
Want to know what a website should cost? Read our honest pricing breakdown.
