Hiring a web developer can feel uncomfortable when you cannot personally judge the code. A candidate can mention APIs, React, PHP, Gutenberg, headless architecture, Core Web Vitals and server configuration, while you may only know that the website needs to work, look professional and generate business. That creates an information imbalance.
Some business owners respond by choosing the cheapest quote. Others choose the person who sounds most technical. Some select a large agency because the size feels safer. None of those methods reliably tells you whether the project will succeed.
You do not need to become a developer to hire one well. You need to evaluate the things a business buyer can verify: evidence of relevant work, clarity of thinking, communication, process, ownership, risk management and whether the proposed solution actually fits the problem.
Start by defining what you are hiring for
“Web developer” can mean several different jobs. You may need:
- A WordPress developer
- A frontend developer
- A full-stack developer
- An ecommerce specialist
- A developer who can work from an existing design
- A designer-developer who can handle the whole website
- A developer for ongoing maintenance
- A team for a larger custom platform
The first hiring mistake is asking one person to solve a problem outside their actual specialty.
For example, an excellent backend developer may not be the right person to design your brand and UX. A strong visual designer may not be qualified to build a complex API integration.
Before posting a job or requesting proposals, write down:
- What you are building or changing
- Which platform you currently use, if any
- The main business goal
- Required functionality
- Important integrations
- Approximate number of pages or content types
- Whether design is already available
- Whether content is ready
- Whether the existing site must be migrated
- Who will maintain the website later
- Your target launch window
You do not need a perfect specification. You need enough context for a good developer to ask intelligent questions. If budget is still fuzzy, start with what a small business website actually costs.
Look for relevant evidence, not a giant portfolio
A portfolio with fifty screenshots can be less useful than three projects similar to yours. Ask the candidate to show work relevant to the actual requirement. If you need WooCommerce, ask for ecommerce examples. If you need a B2B lead-generation site, look for projects with service architecture, case studies, forms and CRM integration. If you need a custom WordPress build, ask what was actually custom rather than assuming every WordPress portfolio item involved development.
For each example, ask:
- What was your role?
- Did you design it, develop it, or both?
- What parts did you personally build?
- What problem was the client trying to solve?
- What platform and tools were used?
- What would you do differently now?
A good developer can explain their contribution precisely.
Be cautious when every answer is “we did everything” but the person cannot describe any implementation decisions.
Ask them to explain the solution in plain English
Technical expertise should increase clarity, not reduce it. Give the developer a real problem from your project and ask how they would approach it. For example:
“We have a service website with 200 existing URLs that already receive Google traffic. We want to rebuild it without losing rankings. What would you do?”
A strong answer may discuss URL inventory, redirects, content mapping, staging, migration, metadata, analytics, Search Console and post-launch monitoring.
A weak answer may simply say, “No problem, we can redesign it in WordPress.”
You are not judging whether they use the exact technical vocabulary. You are judging whether they understand the consequences of the task.
Pay attention to the questions they ask you
Good developers diagnose before prescribing. If you say, “I need a new website,” an experienced person should want to know why.
Useful questions include:
- What is wrong with the current site?
- Who is the target customer?
- Where do leads currently come from?
- What should visitors do on the site?
- Does the current site rank in search?
- Who will edit content?
- Which systems does the website need to connect to?
- Who owns the hosting and domain?
- Is there existing analytics or CRM data?
- Are there accessibility or compliance requirements?
Someone who gives a final price and technology stack before understanding the project may be selling a predefined package rather than solving your specific problem.
Evaluate technical judgment through trade-offs
You do not need to know whether WordPress, Webflow, Shopify or a custom application is technically superior in general.
Ask why the developer recommends one for your case. A good explanation includes trade-offs. For example:
- “WordPress gives you more flexibility and ownership, but it requires maintenance.”
- “Shopify is a strong fit for this store because the commerce workflow is standard, but custom backend behavior may require apps or custom development.”
- “A headless build is possible, but for a five-page brochure site it would add cost and complexity without a clear business benefit.”
Be wary of people who present their favorite technology as the correct answer to every project.
Ask what happens after launch
A website is not finished when the homepage goes live. Ask:
- Who handles updates?
- Who monitors uptime?
- Who updates plugins or dependencies?
- Who manages backups?
- What happens if the site is hacked?
- What support is included after launch?
- How are small changes priced?
- Is documentation provided?
- Can another developer take over later?
A developer does not need to provide permanent support, but the handoff should be intentional.
Protect ownership from the beginning
This is one of the most important non-technical issues. Your business should normally control the primary accounts for:
- Domain registrar
- Hosting
- DNS
- Website administrator access
- Analytics
- Search Console
- Tag Manager
- Email marketing
- CRM
- Payment gateways
- Advertising accounts
- Premium software licenses where practical
The developer can have the access required to work, but your company should not become dependent on an account only they control.
Ask directly:
“Who will own the domain, hosting, website files and administrator accounts when the project is finished?”
The answer should not be ambiguous.
Ask how access will be handled
A developer may need powerful access to your website, hosting, DNS or database. That means access management is part of hiring risk.
Good practice can include:
- Creating separate user accounts instead of sharing your own password
- Giving only the access required
- Using two-factor authentication
- Removing access when the engagement ends
- Keeping backups before major changes
- Avoiding passwords sent repeatedly through insecure channels
If somebody asks for the master password to every business system when they only need WordPress access, ask why.
Check how they handle backups before making changes
For work on an existing website, one of the simplest competence checks is this:
“What will you do before changing the live site?”
A careful developer should think about backups, staging, version control or another rollback path depending on the project.
The exact process varies, but “I’ll just edit it live and we can fix anything that breaks” is not a reassuring default for a business-critical site.
Understand fixed price versus hourly work
Neither pricing model is inherently better.
| Fixed price works well when | Hourly works well when |
|---|---|
| Scope is clearly defined. Deliverables are measurable. Major unknowns are limited. Both sides agree on what counts as completion. | Requirements may evolve. You are debugging an unknown problem. The work is ongoing. Priorities may change from week to week. You want to buy access to expertise rather than one predefined deliverable. |
The problem is not hourly versus fixed. The problem is unclear scope. A fixed-price project with vague requirements creates change-order conflict. An hourly project with no priorities or reporting can burn time without direction.
Whichever model you use, define:
- Deliverables
- Rate or price
- Milestones
- Communication cadence
- Approval process
- What is outside scope
- How additional work is authorized
Compare proposals by scope, not only total price
Suppose one developer quotes $3,000 and another quotes $5,000. That tells you almost nothing until you compare what is included.
The $5,000 proposal may include:
- Discovery
- Custom design
- Copy structure
- Development
- SEO migration
- Analytics
- Testing
- Performance optimization
- Training
- Post-launch support
The $3,000 proposal may include only development from client-supplied designs and content. Both can be fair prices for different scopes. Normalize the proposals before deciding.
Create a comparison table with rows for:
- Strategy
- Design
- Development
- Content
- SEO
- Migration
- Integrations
- Testing
- Accessibility
- Analytics
- Hosting
- Licenses
- Support
- Timeline
- Ownership
Then compare like with like.
Do not use coding tests unless the role requires them
A business owner hiring someone for a normal website project usually does not need to invent a technical coding exam. You are more likely to learn from a small paid discovery task or technical audit. For example, ask the developer to:
- Review the current website
- Identify the top technical risks
- Recommend an architecture
- Explain a migration plan
- Estimate the work in phases
A paid diagnostic gives you evidence of how they think and communicate while producing something useful for the project.
Test communication before the project becomes expensive
Communication quality during sales is often the best it will ever be.
Watch for:
- Do they answer the question you asked?
- Do they explain delays?
- Do they summarize decisions?
- Do they identify dependencies?
- Do they tell you when something is uncertain?
- Do they push back when a request creates risk?
A developer who says “yes” to everything can be more dangerous than one who occasionally says, “I would not recommend that, and here is why.” Technical work contains uncertainty. Professional communication makes that uncertainty manageable.
Look for written process
The process does not need to be complicated, but you should know the sequence. A typical website project may include:
- Discovery
- Sitemap and requirements
- Content planning
- Wireframes or design
- Development
- Content implementation
- Integrations
- QA
- Launch
- Post-launch checks
If the process is simply “pay deposit, we build, you review at the end,” there is a higher risk of discovering major misunderstandings too late.
Ask how change requests are handled
Projects change. A stakeholder remembers a missing feature. A CRM integration turns out to require custom API work. New pages are added. Content arrives late. A professional contract should explain how changes affect cost and timeline.
You want a provider who can say: “That is outside the agreed scope. Here is the additional effort and impact before we proceed.” That is healthier than silently doing extra work and becoming resentful, or surprising you with an unexplained invoice later.
Check references and reputation intelligently
Marketplace ratings, testimonials and reviews can help, but read them rather than only counting stars. Look for patterns:
- Repeat clients
- Long-term relationships
- Comments about communication
- Evidence of solving complex problems
- How the provider handled difficulties
If you hire through a marketplace such as Upwork, platform work history can add useful evidence, but it should not replace your own evaluation.
A developer with a strong marketplace profile can still be wrong for your project. A good independent developer may have little marketplace history because most work comes through referrals.
Watch for portfolio misrepresentation
Ask for live URLs when possible.
Then ask what the person actually did.
Agencies and freelancers sometimes show projects where they handled only one small portion of the work.
That is fine if disclosed. It becomes a problem when a candidate implies they designed and built an entire platform they barely touched.
Specific questions reveal this quickly.
Recognize common red flags
Guaranteed SEO rankings
No developer can honestly guarantee a specific organic ranking.
One technology for every project
If every recommendation leads to the same stack regardless of requirements, the solution may be driven by the provider’s convenience.
No questions before quoting
This usually means the quote is based on assumptions.
The developer wants to own your domain
There are rare operational reasons for providers to manage accounts, but your business should not lose control of its primary identity.
No backup or staging process
Risk increases significantly when important changes happen directly on production with no rollback path.
Very low quote with vague scope
The missing work usually appears later as exclusions, shortcuts or change requests.
Heavy jargon when you ask a simple question
Technical language is sometimes necessary. Using it to avoid clear answers is not.
No written agreement
Even a small engagement should define the basic scope, payment and ownership expectations.
Refusal to document custom work
If the business will depend on custom code, another competent developer should be able to understand it later.
What a good web developer usually sounds like
A strong developer does not need to know every answer immediately. They may say:
- “I need to inspect the current setup before I can answer that accurately.”
- “That feature is possible, but I do not think the cost is justified for your current use case.”
- “There are two reasonable approaches. The first is cheaper now; the second is easier to scale later.”
- “I would not launch until we have mapped the old URLs because you already have organic traffic.”
- “I can build this integration, but the CRM API has a limitation we should account for.”
Those answers show judgment. The ability to identify uncertainty is part of expertise.
Freelancer or agency?
Choose based on the project, not the label.
| A freelancer can be excellent when | An agency or team can be better when |
|---|---|
| Scope fits one specialist. Direct communication matters. Budget is limited. You want a senior person doing the actual work. | Several disciplines are required. The project is large. Timeline requires parallel work. Continuity and capacity are important. Formal project management is valuable. |
Also consider hybrid models. A senior freelancer may lead the project and bring in trusted specialists for design, development or SEO. Ask who will actually do the work, especially when speaking with an agency.
A practical hiring scorecard
Score each candidate from 1 to 5 on:
Relevant experience
Have they solved similar problems?
Understanding
Do they understand your business objective, not only the requested features?
Communication
Can they explain decisions clearly?
Technical judgment
Do they discuss trade-offs and risks?
Process
Is there a credible path from discovery to launch?
Ownership
Will your business control its accounts and assets?
Maintenance
Is there a realistic handoff or support plan?
Commercial clarity
Are price, scope and exclusions understandable?
Trust
Do their examples, claims and behavior match?
This is not scientific, but it forces you to compare factors other than price.
Ten questions to ask before hiring a web developer
- Can you show me two or three projects similar to mine and explain your role?
- What would you need to know before recommending a technical approach?
- What do you see as the biggest risks in this project?
- What is included and excluded from your quote?
- Who will actually do the work?
- How do you test before launch?
- How will existing SEO and URLs be handled?
- Who will own the domain, hosting, website and related accounts?
- What happens if I need changes after launch?
- Can another developer take over the website later without rebuilding it?
The answers will tell you far more than asking, “How many years of PHP experience do you have?”
Final takeaway
You do not need to inspect code to hire a good web developer. Your job as the client is to determine whether the provider understands the problem, has relevant evidence, communicates clearly, makes sensible trade-offs, protects your ownership and has a process for delivering the work safely.
The best developer is not necessarily the cheapest, the most expensive, the highest-rated or the person using the newest technology. It is the person or team whose capabilities match the project and whose working method reduces the chance of expensive surprises.
Define the problem. Ask for relevant evidence. Compare scope. Protect your accounts. Start with a smaller paid diagnostic when uncertainty is high. Those steps make technical hiring much less dependent on technical knowledge. If you are comparing web developers or proposals and the technical differences are difficult to evaluate, a neutral review of the scopes and architectures can often reveal whether you are actually comparing equivalent offers.
Frequently asked questions
How do I know if a web developer is good if I cannot code?
Evaluate relevant project evidence, how clearly they explain trade-offs, the questions they ask, their delivery process, ownership policy, testing approach and communication. You do not need to review code personally to judge professional behavior and technical reasoning.
Should I hire a freelancer or web agency?
Use a freelancer when the scope fits one specialist and direct communication is valuable. Use an agency or team when the project requires several disciplines, more capacity or formal project management.
Is fixed price or hourly better for web development?
Fixed price works well for clearly defined deliverables. Hourly works well for evolving, uncertain or ongoing work. Clear scope and authorization rules matter more than the pricing model itself.
Who should own my website domain and hosting?
Your business should normally control the primary domain, hosting and key service accounts, while giving the developer the access needed to do the work.
What is the biggest red flag when hiring a developer?
There is no single red flag, but vague scope, no discovery questions, guaranteed outcomes, unclear ownership and a lack of backup or testing process are all reasons to investigate further.
