Choosing a web developer is one of the highest-stakes decisions most organizations make, and almost every guide on the topic is written by someone who wants you to hire them.
Think about that for a second. The top search results for "how to choose a web developer" are written by web development agencies. Every evaluation framework, every list of criteria, every "what to look for" section is calibrated to make that particular agency look like the obvious choice. It's like asking a car salesman which dealership to buy from.
I'm not selling development services. FatLab is a managed WordPress hosting and support company. We manage roughly 200 websites, and the vast majority of them were built by someone else. That means I've spent 25 years seeing the downstream consequences of hiring decisions: the developer who built a gorgeous site on a bloated commercial theme, the agency that locked the client out of their own hosting, the freelancer who disappeared three months after launch. I've inherited all of it.
This guide is what I wish our clients had read before they chose their developer. Not a checklist designed to sell you on any particular vendor type, but an honest framework from someone who cleans up the messes and maintains the successes. If you're figuring out how to choose a web developer, start here.
Before You Start Looking: Define What You Actually Need
Most organizations start the developer search by browsing portfolios. That's backward. Before you evaluate anyone else, you need to evaluate your own project.
I always tell clients the same thing: make a list of everything you want your website to do. Not "modern design" or "SEO optimized." Those aren't requirements. They're buzzwords. Every professional website in 2026 should look good and follow SEO best practices. That's a given, not a differentiator.
What I mean is functional requirements:
- Can users log in?
- Can they make purchases?
- Do you need a members-only section with gated content?
- Do you need event registration, a donation system, or integration with your CRM?
If it doesn't have a bullet point, it's not in scope.
If we can start with a list of things you want me to build, and I can check those off, and at the end of the project, I can show you that I've built everything on this list, then we're both going to be really happy.
The organizations that struggle most with developer selection are those that can't articulate what they need. When the scope is vague, every proposal looks different because vendors are guessing. You can't compare apples to apples when each vendor interprets a different scope. If you want to formalize those requirements into a structured document, our website RFP template walks through each section with guidance on what to include.
If you've already written an RFP for your website project, you've done a lot of this work. If you haven't, doing this exercise first will make every subsequent step easier. And if you're working on a redesign specifically, understanding what redesign actually means versus a rebuild will save you from a common and expensive miscommunication.
The Four Types of Web Developers (and What Each Really Costs)
Not all developers are the same, and understanding the structural differences between provider types matters more than most people realize. Each type comes with tradeoffs that are independent of individual talent.
Solo Freelancers
Freelancers typically charge $50 to $150 per hour in the US, with project costs ranging from $2,000 to $15,000 for a typical business site. The advantages are real: direct communication with no middlemen, lower cost, and often deep specialization in a particular platform.
The structural risk is also real. A freelancer is a single point of failure. If they get sick, burn out, or simply move on to other work, your project stalls and your ongoing support disappears.
I've seen this pattern dozens of times. The freelancer does solid work, the site launches, and six months later, the client can't get a response to their emails. There's no backup. There's no team. There's just one person who has moved on to the next thing.
Freelancers work best for well-defined projects when you have some internal technical capacity to manage the relationship and aren't relying on them for ongoing support.
Boutique Agencies (2 to 15 People)
Boutique agencies charge $100 to $200 per hour, with projects typically running $10,000 to $75,000. You get skill diversity (design, development, and strategy), established processes, and continuity if one person leaves.
The risk here is key-person dependency. In many boutique shops, the founder is the agency. If they step back, the quality and attention change. Boutique agencies can also get stretched thin across too many projects at once, which means your project gets the B-team's attention while the founder focuses on the biggest client.
Large Agencies (50+ People)
Large agencies charge $150 to $350 per hour, with projects from $50,000 to $500,000 and up. You get deep specialist benches, formal project management, structured QA, and financial stability.
What you may also get: layers of communication between you and the people actually building your site. The person who sold you on the project during the pitch may not be the one who manages it day-to-day.
Account managers and project managers add overhead that you're paying for, and on smaller projects, you may get assigned junior staff while senior people handle bigger accounts.
Offshore Teams
Offshore teams charge $15 to $60 per hour with project costs from $3,000 to $30,000. The cost savings are significant, sometimes 3 to 5 times lower than US-based rates.
But the quality variance is extreme. I've seen offshore work that was perfectly competent, and I've seen sites delivered with 40-plus unused plugins, hardcoded content that can't be edited, and security vulnerabilities baked into the foundation.
Time zone challenges, high developer turnover (your developer may change week to week), and limited understanding of your market context are structural issues, not individual ones.
Offshore works best when requirements are locked down and you have strong internal project management. It works poorly when the project requires back-and-forth collaboration, subjective design decisions, or understanding of a local audience.
How to Evaluate a Web Developer's Portfolio
Most portfolio advice says, "Look at their work." That's unhelpful if you don't know what you're actually evaluating. Here's what matters.
Visit the Live Sites, Not Screenshots
Screenshots in a portfolio are curated. They show the best version at the best moment. Live sites reveal truth. Pull up their portfolio sites on your phone. Does the experience hold up? Run them through Google PageSpeed Insights. Click around. Do the forms work? Is the site still online, or has it been redesigned by someone else?
When we evaluate other vendors' portfolio sites on behalf of our clients, we go further:
- We look at the markup to see whether they're building custom themes or using bloated commercial ones.
- We check how many plugins appear to be installed and what they're using for common features like forms.
- We look at the CSS to see whether it's clean and purposeful or just auto-generated by a page builder.
Most clients aren't doing this level of evaluation, which is why so many end up with sites that look polished on the surface but are difficult and expensive to maintain.
A portfolio site that's been completely rebuilt by a different developer tells you something important about the longevity of that relationship.
Look for Similar Complexity, Not Similar Industry
You don't need a developer who's built sites for your exact industry. You need one who's handled your level of complexity. If you need membership functionality, look for sites with login areas and gated content. If you need e-commerce, look for operational stores. The industry doesn't matter nearly as much as the technical scope.
Case Studies Over Galleries
A developer who writes up their process, including the problem, their approach, and what they learned, demonstrates analytical thinking. A gallery of pretty screenshots demonstrates nothing about process, problem-solving, or what the client experience was actually like.
Case studies that include measurable results indicate a developer who thinks about outcomes, not just deliverables.
Portfolio Red Flags
- When every site in the portfolio looks the same, you're looking at template-based work. That's not inherently bad, but you should know what you're getting and what you're paying for. A $30,000 custom build that's actually a $5,000 theme with a logo swap is a problem.
- If there are no live links, only screenshots, ask why. Sites may have been taken down, redesigned by someone else, or never actually launched.
- If the most recent work is from 2023, that's a signal. Either they haven't done notable work recently, or they haven't maintained their own marketing. Neither is encouraging.
The Questions That Help You Choose a Web Developer
This is where most organizations waste their evaluation process. They ask, "Can you do this?" and every vendor says yes. The questions that actually matter are the ones that reveal how a vendor thinks, not just what they claim to offer.
Ask Whether They Have Real Developers
This matters more than most organizations realize.
Ask whether people write their own code, understand the server stack, and aren't just installing commercial themes and plugins. I've seen the point-and-click developer type ruin too many projects.
There are two types of vendors in this industry, and both call themselves "developers." One writes custom code, builds custom themes, and can solve any design or functionality challenge with creativity and technical skill. The other installs a commercial theme, changes some colors, adds a logo, and loads up plugins for every feature.
The problem is that both types produce sites that can look equally polished in a portfolio. I've seen beautiful websites that are absolute spaghetti code underneath. The difference shows up six months after launch when you need something changed and discover that your entire site is locked into a page builder that only the original developer knows how to use. Or when a plugin update breaks three other plugins because the site was held together with duct tape from the start.
To cut through this, ask pointed questions:
- Do they build custom themes or use commercial ones?
- Do they build their own plugins or rely entirely on third-party options?
- Can they work through any design challenge, or are they limited by how a theme was built?
- Is their answer to every problem "install another plugin," or do they think about the system as a whole?
These questions will tell you whether you're hiring a developer or a theme installer, and whether the resulting site will be maintainable for years or a tangled dependency chain from day one. For concrete examples of how to phrase these kinds of requirements clearly in writing, see our website RFP examples comparing effective versus ineffective language.
Listen for Questions, Not Answers
A competent developer's first response to your project description should be a list of questions, not a quote. "What CMS are you currently on? What does your content update workflow look like? Who maintains this after launch? What are your traffic patterns?"
If someone quotes you before understanding your situation, they're guessing.
Watch for "No"
Developers who agree with everything you say aren't evaluating your project. They're selling. A good developer will push back on requests that don't serve your goals. "You don't need a custom booking system. Calendly integrates cleanly, and you won't have maintenance overhead." Willingness to recommend against billable work is one of the strongest trust signals you can find.
Ask About Their Process
Ask them to walk you through how a project goes from kickoff to launch. A developer who wants to jump straight to design and development is skipping the most important part. A proper discovery phase, where the team understands your business, your users, and your content strategy, should precede any visual or technical work. If there's no discovery phase in the proposal, the developer is building on assumptions.
The most common scenario when a client is unhappy with the end product: it's not the quality of what was built. It's that they didn't get what they wanted because they didn't know what they wanted.
Ask What Happens After Launch
This is the question that separates serious developers from transactional ones:
- Who maintains this site after it goes live?
- How do you update content?
- What's the plan for security patches?
- What happens when you need changes in six months?
If the proposal ends at "launch," you're buying an artifact, not a solution.
How to Check References That Actually Tell You Something
Every developer will hand you a list of their happiest clients. Calling those people and asking "Were you happy?" gets you nothing useful. Here's how to get real information.
Ask About What Went Wrong
"Walk me through how the project actually went. Was the timeline what they originally estimated?" This reveals estimation accuracy.
"What happened when something went wrong or needed to change mid-project?" This reveals how the developer handles stress and ambiguity. Every project has problems. What matters is how the developer responds to them.
Ask About the Aftermath
"What happened after the site launched? Are they still involved?" and "If something breaks on your site today, who do you call?" These questions reveal the post-launch reality. Many agencies are great during the build and gone after the check clears. The reference may have been thrilled with the project and now be completely stranded.
Ask the Hard Question
"Knowing what you know now, would you hire them again? For what kind of project?" This forces specificity. And ask for a reference from a project that didn't go perfectly. How the developer responds to that request is itself revealing. A mature developer will have a candid answer. An immature one will insist everything has always gone perfectly, which is either a lie or evidence of insufficient experience.
Go Beyond Provided References
Check Clutch, GoodFirms, and Google Reviews for unfiltered feedback. Look for patterns in negative reviews more than individual complaints. Visit the developer's portfolio sites and check whether those clients are still using the same developer. A portfolio full of sites that have been redesigned by someone else tells you about relationship longevity.
The Ownership Questions Nobody Asks Until It's Too Late
Under US copyright law, the creator of a work owns the copyright unless there's a written agreement assigning those rights. If your contract doesn't explicitly address intellectual property, the developer may legally own your website's custom code and design.
This isn't hypothetical. I've helped organizations untangle ownership disputes where the developer controlled the hosting, the domain was registered under the developer's account, and the site couldn't be moved without the developer's cooperation. When that relationship goes sour, you're stuck.
What Your Contract Must Cover
Intellectual property assignment. The contract should state that upon final payment, you receive full ownership of all custom deliverables: design files, custom code, and content created for the project. The developer retaining rights to underlying frameworks and reusable components is standard and reasonable.
Administrative access. You must have admin access to your CMS, hosting account, domain registrar, and all third-party services (analytics, email, forms). Request all credentials documented and transferred. Never accept a setup where the developer is the only one with admin access.
Hosting independence. Your site should be deployable on any compatible hosting environment, not locked into the developer's proprietary hosting. If the developer provides hosting, the contract should specify your right to migrate with reasonable assistance. And your domain registration should be in your name and your account. Never let a developer register your domain under their account.
Continuity planning. What happens if the developer goes out of business or stops responding? Your contract should address access to all assets, documentation sufficient for another developer to take over, and the absence of proprietary lock-in that prevents migration.
Contract Red Flags
- A developer who retains IP ownership "until final payment" with vague payment terms is creating pressure points for disputes.
- Hosting bundled with development and no migration clause means you're locked in.
- No mention of source code access may mean you're licensing your own site rather than owning it.
These aren't theoretical concerns. We see them regularly in our work, managing sites built by other developers.
For a deeper look at contract warning signs and how to spot problematic proposals, our guide to red flags in website vendor proposals covers what to watch for before and during the engagement.
How Pricing Works (and What Each Model Tells You)
Understanding how a developer prices their work tells you a lot about how they operate.
Hourly billing ($100 to $200 per hour at typical US agency rates) signals flexibility but creates open-ended financial exposure. Hours add up fast. A "quick change" at $150 per hour can easily add up to $600 after meetings, testing, and deployment. Always request a not-to-exceed estimate even with hourly billing.
Fixed-price projects ($5,000 to $200,000 depending on scope) signal that the developer is confident in their estimating. But a fixed price requires a thorough scope document. If the proposal is vague about what's included, "fixed price" becomes "fixed starting point," and change orders can be more expensive than the equivalent hourly work. Watch for artificially low fixed bids designed to win the contract.
A cheap proposal is one that's designed to win the project, give a low number without defining what you're going to build. The theory is: win the client, then deal with it later.
Retainers ($1,500 to $6,000 per month) signal a long-term relationship orientation. A genuine retainer should include proactive work: the developer identifying and addressing issues before you notice them. If the retainer is just pre-paid hourly billing where they wait for you to submit tickets, it's not really a retainer.
As a non-technical person evaluating proposals, look for whether the vendor has allocated hours to the budget or allocated scope to the price. If neither, ask for it.
This is also where getting multiple bids helps. You'll be able to see the average, and if one bid is dramatically lower or higher, you'll know to ask why. If you like the lowest bidder, go back to them and discuss how they arrived at their price. You'll probably find that things weren't included, the scope wasn't defined, or they're using a fundamentally different approach. It's important to get those things nailed down before you sign an agreement.
For a structured framework for comparing proposals side by side, see our guide to evaluating website proposals.
The Build Is 20% of the Story
Here's what nobody in the development world wants you to focus on: the build phase is temporary. The maintenance phase is permanent. A website that launches on day one will need updates, security patches, content changes, performance monitoring, and technical support for years to come. Yet almost the entire evaluation process focuses on the build and ignores everything that comes after.
We see this play out in real time. It's a common scenario for us: an organization calls and says, "We just launched a new website, and we've decided we're not going to use the vendor who built it for hosting and support because we're not happy." That unhappiness almost always traces back to a loose scope, which traces back to the evaluation process.
If the client had been truly happy with the outcome, they wouldn't be looking for another vendor before the site is even a month old.
The longer-term pattern is just as common. An organization invested $20,000 to $50,000 in a website build, had no ongoing maintenance plan, and three years later has an outdated, vulnerable, underperforming site that needs another major investment. The cost of ongoing maintenance, typically $200 to $500 per month, is a fraction of the cost of periodic rebuilds. But most evaluation processes don't account for the total cost of ownership.
Think about it this way: a $15,000 site with $300 per month maintenance over five years costs $33,000 total, but you have a healthy, secure, continuously improving site the entire time. A $15,000 site with no maintenance that needs rebuilding every three years costs $30,000 over six years, and during that time, you've had two painful migrations, months of vulnerability, and SEO disruption from each relaunch. The raw numbers look similar, but the maintenance path delivers dramatically more value.
What to Establish Before You Sign
Before you commit to a developer, get clear answers on these post-launch questions:
Warranty period. Most professionals include 30 to 90 days of bug fixes after launch. Make sure "bug" is defined separately from "change request."
Ongoing support options. Is maintenance available? At what rate? What's the typical response time for urgent issues? Is there a separate support team, or is it the same person who built your site?
Training and documentation. Will you receive training on managing your content? Is there documentation for site-specific features? What happens when your content editor has a question three months from now?
Technology updates. Who handles CMS updates, plugin updates, and security patches? How often? Is there a testing process, or are updates applied directly to production?
One of the most common misconceptions is that hiring an agency means they have ongoing support. In practice, most agency-client relationships are project-based. The agency builds the site, does a handoff, and moves on. If you need changes six months later, you're either paying project rates again or discovering that your "agency" has moved its team to other clients.
The build agency and the ongoing management partner may need to be different entities. Many agencies are structurally terrible at maintenance. They want the next big project, not your monthly update requests. Recognizing this upfront and planning for it will save you significant frustration.
The Agency Trick Nobody Talks About
I want to address something the other guides won't: how agencies make money, and how that affects the advice they give you.
Agencies profit from complexity. A custom build is more billable than a theme implementation. Proprietary page builders create ongoing dependency. And recommending a dozen plugins for functionality that could be handled with clean custom code creates future revenue from updates.
This isn't necessarily malicious. Most agencies genuinely believe their approach is the right one. But when you're evaluating proposals, understand that every vendor has a financial incentive that shapes their recommendations. The agency recommending a $75,000 custom build may be right, or they may be right-sizing the project to fit their revenue targets.
There's no regulatory body in our industry. Pricing can be all over the place, so you need someone looking out for obvious price gouging.
We see this firsthand. We recently reviewed a proposal for a nonprofit in Washington, DC, where the vendor bid $150,000 for a website I would have built for a fraction of that. The organization didn't have the technical background to recognize the disconnect between the scope and the price. Without someone reviewing proposals who understands the technical implementation, price gouging like this goes unchecked.
One practical way to evaluate this is to ask what off-the-shelf solutions they considered before proposing a custom build. A developer who went straight to "we'll build everything custom" without considering simpler alternatives may be optimizing for their revenue, not your outcomes.
A Decision Framework for How to Choose a Web Developer
Forget the 14-step evaluation spreadsheets. The decision comes down to a few core questions.
Do they understand your project before proposing a solution? If they're quoting you a price before asking detailed questions about your needs, they're guessing. If their first meeting is mostly them asking you questions and genuinely listening to the answers, that's a strong signal.
Can you see evidence of their process? Not their portfolio. Their process. How do they move from discovery to design to development to launch? If they can't articulate this clearly, they probably don't have one.
Do they talk about what happens after launch? A developer focused only on the build is selling a transaction. A developer who proactively discusses maintenance, training, and ongoing support is thinking about your long-term success.
Are they honest about tradeoffs? Every approach has downsides. A developer who only talks about the benefits of their recommendation, and never mentions the tradeoffs, isn't being straight with you. This goes for pricing, too. The lowest bid has tradeoffs. The highest bid has tradeoffs. A good developer explains them.
Do they own their mistakes? Ask for a reference from a project that had problems. Ask what they learned. If every project in their history were perfect, they're either lying or haven't done enough work to encounter real challenges.
For Nonprofits and Small Organizations
If you're a nonprofit working with a limited budget, a few additional considerations apply.
First, be honest about your budget. Don't sugarcoat it with promises of portfolio exposure or referrals.
Don't promise us a great portfolio piece. Don't promise your members will hire us. In 25 years of business, I have yet to be made or broken by such promises. I value them at zero dollars.
Being upfront about budget constraints attracts vendors who genuinely want to work with your type of organization. Playing games attracts the wrong kind of vendor.
Second, understand that your website is a 24/7 window into your organization. Especially for organizations with membership portals, dues collection, and event management, this is not the place to cut corners. A well-built website will serve you for years. A cheap website is rarely cheap once you factor in the costs of fixing, rebuilding, or working around it for the next three years.
Third, if your organization has procurement rules requiring competitive bids, run an honest process. Vendors can tell when an RFP is a theater, when the organization already knows who they're hiring, and they're just collecting the required number of bids to satisfy the board. The good vendors won't participate again, and you'll lose access to them for future projects. Our nonprofit website RFP guide covers this in more detail.
What We See After the Handoff
I want to close with something that only someone in my position can tell you. Because we manage sites built by dozens of different agencies and developers, we see patterns that individual clients never would.
The sites that work best long-term share common characteristics: clean custom themes with minimal plugin dependency, clear documentation, open-source CMS on independent hosting where the client controls all credentials. The developers who built these sites thought about what would happen after they moved on. They built for maintainability, not just launch day.
The sites that become problems share their own patterns: proprietary page builders that only the original agency can edit efficiently, 30-plus plugins when 10 would do, no documentation, hosting tied to the developer's account, and no one responsible for security patches and updates.
The choice you make isn't just about who builds your site. It's about what you'll be living with for the next three to five years. A developer who builds for the long term, not just for the portfolio screenshot, is the single best investment you can make in your organization's online presence.
Frequently Asked Questions
How long does it take to build a website with a professional developer?
A typical business website takes 8 to 16 weeks from kickoff to launch, depending on complexity. Simpler brochure sites can launch in 4 to 6 weeks, while sites with custom functionality, such as membership portals, e-commerce, or CRM integrations, often take 4 to 6 months. Be wary of any developer who promises a complex site in two weeks, because that usually means a template with minimal customization.
Do I need to hire a local web developer, or can I work with someone remote?
Geographic proximity matters far less than communication quality and process. A remote developer with a structured workflow, regular check-ins, and clear documentation will outperform a local developer who wings it. What matters is whether they have a defined process for collaboration, not whether you can drive to their office.
How much should a small business website cost in 2026?
For a professionally built WordPress site with a custom design, expect to pay $8,000 to $25,000 from a US-based developer or boutique agency. Sites with complex functionality, such as e-commerce, membership systems, or custom integrations, typically cost $25,000 to $75,000. If you're getting quotes significantly below these ranges, ask what's being cut, whether that's custom design, responsive testing, or post-launch support.
What should I do if my web developer stops responding?
First, verify you have admin access to your hosting account, domain registrar, CMS, and all third-party services. If you do, you can engage a new developer to take over. If you don't have access, you may need to escalate through your hosting provider or, in worst cases, consult a lawyer about your contract terms. This is exactly why establishing ownership and access credentials before the project starts is so important.
Should I hire a freelancer or an agency for my website?
The right choice depends on your project complexity and your need for ongoing support. Freelancers work well for straightforward projects when you have some internal technical capacity and don't need long-term maintenance. Agencies offer more resilience and skill diversity but cost more. For most organizations that need a site maintained for years, the continuity an agency provides is worth the premium.
How do I know if a web developer is overcharging me?
Get three to five proposals for the same well-defined scope and compare them side by side. If one bid is dramatically higher or lower than the average, ask the vendor to explain their pricing in detail. Look at whether hours are allocated to specific tasks or if the number feels arbitrary. A legitimate developer can walk you through exactly where your money is going and why each line item exists.
FatLab Web Support manages roughly 200 WordPress websites for nonprofits, associations, and organizations nationwide. We don't sell development services, which means we can be genuinely neutral about who you hire to build your site. What we do is make sure it stays healthy after the build team moves on. If you're looking for ongoing WordPress hosting, maintenance, and support, get in touch.