Everything you need to know to hire the right web developer — without getting burned

1. Do you need a web developer?

Before you hire anyone, ask whether you need a developer at all. Plenty of businesses hire developers when a website builder would have done the job fine. Plenty of others use website builders when they needed a developer instead and spend years paying the price in performance, limitations, and eventual migration costs.

Here's the clearest version of the answer: if your site is purely informational — your name, what you do, contact information, maybe a gallery — and you're comfortable maintaining it yourself, a platform like Squarespace or Wix is a legitimate option. For a basic online presence, a $17–$23 per month plan does the job (as of mid-2026).

But "comfortable maintaining it yourself" carries a lot of weight. The moment you need something the platform doesn't natively support — a custom booking flow that actually fits your service model, a client portal, a quote calculator, payment processing with specific business logic, a direct integration with your CRM — you're either bolting on third-party plugins (each with their own monthly cost, security exposure, and integration fragility) or you're calling a developer anyway to hack something into a platform that wasn't built for it.

The harder issue is what happens later. When you want to move to a faster server, change hosting providers, or hand the site off to a different developer, you can't. You don't own the code. You're renting access to an opinionated platform, and the moment you want out, you start over from scratch. Every URL you've built rankings on needs a redirect map. Every piece of copy has to be re-entered somewhere new.

If you're on the fence, the framework at DIY website vs. hiring a developer walks through specific scenarios and gives you a structured way to think through the decision before committing either way.

2. Freelancer vs. agency vs. boutique developer

Once you've decided you need a developer, the market splits into three main categories. They're not interchangeable, and the right fit depends on your scope, budget, and how you prefer to communicate.

Freelancers are individual contractors, usually running multiple clients concurrently. The quality range is enormous: a CS student charging $25 an hour on one end, a senior developer with 15 years of specialized experience at $150+ on the other. One thing the hourly rate doesn't tell you is specialization. A WordPress freelancer who has never written a server-side script is a poor fit for a site with custom business logic, and vice versa: a back-end developer with weak HTML and CSS will deliver a site that functions but looks like it was built in 2009. The risks are availability (one person is a single point of failure—if they're sick, overbooked, or unresponsive, your project stalls) and documentation (solo operators don't always write code that someone else can maintain without a week of archaeology). The upside is direct access and, at the right level of experience, craftsmanship at a reasonable cost.

Agencies are teams: account manager, project manager, designer, front-end developer, back-end developer. The organizational accountability is real—if someone on the team drops the ball, there's infrastructure to catch it. The downside is that the person you meet in the sales conversation is rarely the person building your site. Project handoffs between the designer, the front-end developer, and the back-end developer create the kind of translation friction that turns a clean design mockup into code that looks slightly different in every browser. Everyone on the org chart who isn't writing code still gets baked into the price. Agency quotes for a 5–10 page marketing site often run 2–4x what a capable independent developer charges for the same deliverable. For a small business marketing site, the extra coordination layers frequently add cost without adding value.

Boutique developers occupy the middle: one person (or a very small team) operating as a professional entity with an LLC, real contracts, and defined deliverables. You talk directly to the person who writes every line of code — which matters more than it sounds. When design and development happen in the same head, CSS doesn't fight the layout intent, and performance decisions aren't made by a separate team with different priorities. For the $2,800–$5,000 marketing site or web app that most small businesses need, the boutique model is often the better fit — better communication, lower overhead, and a developer who has skin in the relationship, not a ticket in a project management queue.

For a deeper comparison of what agency overhead actually costs versus what you get, the ArdinGate vs. Agency comparison breaks it down side by side.

The Freelancer vs. Agency page covers the specific tradeoffs for projects at different sizes and complexity levels, with a framework for deciding which model fits your timeline and risk tolerance.

3. Custom code vs. WordPress vs. page builders

"What platform are you building on?" is one of the most important questions you can ask, and the answer matters far more than most clients realize going in. The platform decision affects load speed, security surface, ongoing maintenance burden, portability, and what the site can actually do five years from now.

WordPress powers roughly 43% of the web, which says something about its accessibility — not necessarily about its suitability for your specific project. It started as a blogging platform and was extended over 20 years into something that handles almost anything, but that extensibility comes at a structural cost. Every plugin is a dependency, a security surface, and a performance hit. A site running 12 active plugins has 12 separate update cycles, 12 potential compatibility conflicts, and 12 different codebases that all need to stay synchronized with each other and with whatever version of WordPress core shipped last week. The WordPress vs. custom code comparison goes deep on this.

The performance gap between WordPress and a lean custom build is structural, not incidental. WordPress carries overhead by design: a theme framework loader, a plugin activation system, multiple database queries per page load, and Gutenberg block editor markup. A well-optimized WordPress install can perform well, but it requires deliberate effort to overcome built-in weight. A hand-coded custom PHP site has none of that overhead to begin with, which is why it consistently loads faster on mobile—especially important because Google rewards fast-loading sites in search rankings and fast pages have lower bounce rates.

Page builders (Squarespace, Wix, Webflow) are the "no developer required" option, and they've improved substantially. Squarespace's templates look professional. Wix's drag-and-drop is accessible to non-technical users. Webflow offers CSS control. The fundamental limitation isn't the feature set, but what you don't own. Your site lives on the platform's infrastructure. Your hosting options are whatever the platform offers. Your design exists inside a proprietary system that can't be exported and run somewhere else. When the platform changes pricing, deprecates a feature tier you rely on, or decides your business type violates its updated terms, your options are limited to comply or rebuild. The Custom code vs. page builders comparison details when the builder wins and when custom code makes more economic sense.

Hand-coded custom sites are exactly what they sound like: a developer wrote every file, including the PHP router, HTML templates, CSS, contact form handler, and any database queries the site needs. Nothing is a black box. You can audit it, move it to any standard PHP hosting environment, hand it to any developer with PHP experience, and extend it in any direction without asking a platform's permission. The tradeoff is build cost: writing from scratch takes more time than dropping content into a pre-built template. For a 5–15 page marketing site with real traffic, the cost difference is often smaller than clients expect, and the long-term maintenance overhead is substantially lower because there's no plugin ecosystem to babysit.

4. How web development pricing really works

Web development quotes confuse almost everyone who hasn't hired a developer before. Two quotes for "a 5-page website" might come in at $900 and $9,000. Neither number is necessarily wrong — they're describing fundamentally different products, even though they both technically result in a website that has five pages.

The low end typically means: a developer will install a pre-built theme, drop in your content, and do minimal customization. Fast to do, fast to price, functionally adequate. The site works, looks like the template it's based on, and is maintained via whatever update cycle the theme vendor ships.

The higher end typically means: a developer is writing the site from scratch. Custom CSS, custom layout, technical SEO built in at the code level, page-speed optimization from the start, the behind-the-scenes labels that tell Google what your business is, and clean PHP with no plugin dependencies. That takes time and reflects the cost of skilled technical labor, not padding.

Here's what moves the number:

• Custom vs. template: Building from scratch costs more than filling in a template. Both can look good. Only one is unique, fully extensible, and free of third-party theme licensing.
• Page count and feature scope: A 3-page informational site and a 12-page site with a client portal, a quote calculator, and a booking flow are not the same scope. Writing accurate scopes is the single biggest factor in getting comparable quotes.
• Design included or not: If the developer is designing the site as well as building it, that work is additional. If you're supplying final design files in Figma or equivalent, the developer is implementing, not originating.
• Copywriting: Most developers don't write copy and most quotes don't include it. If there's no explicit line item for copywriting, you're expected to supply it. Many clients discover this on launch week when placeholder text is still sitting in final pages.
• Hosting and support structure: A one-time build, a build with managed hosting, and a build with a monthly retainer for ongoing changes are three different products with three different price structures.
• Integrations: Connecting your site to a CRM, a booking calendar, a payment processor, or a custom API is additional scope. It's not hard to miss in the initial conversation and painful to add as a surprise at the end.

On hourly vs. project pricing: project pricing is nearly always better for you as the client. When the developer quotes a flat project fee, they absorb the risk of scope estimation errors. When they quote hourly, you absorb it. An hourly engagement for a "simple" website that takes longer than expected transfers the overrun cost entirely to you. For defined scope, push for a fixed project price. For truly open-ended ongoing work (monthly content updates, on-call support, evolving feature development), hourly or a retainer is the right fit.

The Website Cost Estimator lets you build out your scope and get a live range before any calls, which is useful for calibrating expectations. The Pricing page covers ArdinGate's specific tiers. Single-page builds start at $1,200. Multi-page business sites run $2,800–$5,000.

5. How to evaluate a developer's portfolio

A portfolio is your strongest signal. Unlike a discovery call, it can't be rehearsed. Here's how to evaluate it properly.

Check the live sites, not just screenshots. Screenshots are curated. Live sites behave differently on different devices and network conditions. Load each portfolio site on your phone. Does it feel fast? Does the layout hold up on a small screen? Is the text readable without zooming? Does anything feel broken? A site that looks impressive in a polished screenshot but loads slowly on mobile tells you that page speed wasn't a priority during development.

Run a performance check. Go to PageSpeed Insights (pagespeed.web.dev) and plug in a URL from the portfolio. Look at the mobile score specifically—mobile is where most small business traffic arrives and where page-speed performance is hardest to nail. A developer claiming to build fast, SEO-optimized sites whose portfolio scores in the 40s on mobile is showing you something important.

View the source. Right-click any portfolio site and select "View Page Source." You don't need to be a developer to read signals here. Clean, structured HTML with clear heading hierarchy and organized markup is a good sign. Hundreds of lines of auto-generated classes, inline styles on every element, and five different JavaScript libraries loading simultaneously is a page builder or block editor site — not custom code.

Look for variety vs. repetition. A WordPress developer who built 30 sites all using the same premium theme didn't build 30 different sites. They deployed one template 30 times. The portfolio will give it away: similar layouts, same font pairings, same section structure across clients. Ask specifically what platform each portfolio site uses and whether the developer wrote the theme from scratch or used an existing one.

Ask to talk to a past client. Not a written testimonial selected by the developer — an actual conversation. Ask the client how the process went, whether the developer communicated well, whether the final site matched what was promised, and whether there were any surprises in scope or billing. A developer confident in their work will connect you without hesitation.

6. Red flags to watch for before you sign anything

Most web project failures are predictable. These patterns appear before the contract is signed, but clients often don't know what to watch for.

They don't ask about your business. The first substantive questions should be about what you do, who your customers are, what you want visitors to do when they arrive, and what isn't working about your current presence. If the first question is "what colors do you like" or the proposal arrives before discovery happens, you're talking to someone who builds decorations, not solutions.

No contract, or a contract without clear IP terms. Every web project should have a written agreement. It should state explicitly who owns the code when you're done. "We'll host it for you" with no code delivery clause is not ownership—it's a dependency. Get in writing that you receive the full source code on completion and final payment, and that you retain full rights to it with no restrictions on hosting location or who can maintain it.

A portfolio that's all one template or all one client type. Repetition at scale is a sign of a template deployer, not a developer. Ask how each portfolio site was built. If the answer for every project involves the same premium WordPress theme or the same Elementor layout, you're getting a template with your logo swapped in.

Can't explain technical decisions in plain language. A competent developer can explain why they made the choices they made in terms that are meaningful to you. "I'm proposing hand-coded PHP because it gives you a portable codebase with no plugin dependencies, and it's significantly faster to load than a comparable WordPress install for your use case" is a clear answer. "It's best practices" or "it's what I always use" isn't.

They registered your domain in their own account. Your domain registrar account must be in your name, full stop. A developer who registered your domain under their own account without your explicit consent holds leverage over your entire online presence. Transfer immediately if this has happened. Managed hosting — where a developer runs your site on their server infrastructure as a paid service — is different and completely normal, provided you can take the source files and move when you want to. The domain situation is the red flag, not managed hosting.

"Unlimited revisions" in the contract. This sounds like buyer protection. It usually isn't. Developers who offer unlimited revisions either plan to rush sign-off to close the project or will eventually become resentful of an engagement they can't complete on any timeline. Clear revision rounds ("two rounds of design revisions included, additional revisions billed at the hourly rate") are better for everyone.

See what to look for in a web developer contract for a full breakdown of the clauses that protect you and the ones that protect only the developer.

7. What belongs in the contract

A web development contract doesn't need to be 30 pages, but it needs to explicitly address what causes disputes. Most project conflicts come down to one of four issues: scope, IP, payment, or timeline. A solid agreement covers all four before work starts.

IP and code delivery. All deliverables become your property on final payment. The contract should say this explicitly. The developer retains rights to their own pre-existing code libraries and internal tools, but everything built for this project is yours — hosted wherever you choose, modified by whomever you choose.

Scope definition. Write down what's included: not "a website" but a specific list of pages, features, integrations, and what "done" looks like for each. The more specific the scope, the less ambiguous the change order conversation becomes. If the contract says "contact form" but you needed a multi-step intake with conditional routing, that's a scope gap that creates a billing dispute. Specificity protects both sides.

Revision rounds. Define how many included revision cycles, what counts as a revision vs. scope change, and the rate for extras. "Two rounds of design revisions; functionality changes outside the original scope billed at $X/hr" is clear and fair. "Unlimited revisions until you're satisfied" is a setup for conflict.

Timeline and milestone checkpoints. Specific delivery dates for major phases (design review, staging build, content handoff deadline, launch date) create accountability on both sides and give you a clear signal if work is falling behind before it becomes a crisis.

Payment terms. How much is due when: typically 30–50% upfront, a milestone payment at a defined review point, and the remainder at launch. What happens if you request a scope addition mid-project: change order process with written approval. What happens if the project is cancelled partway through: compensation for completed work, defined handling of any unused portion of the initial deposit.

Termination clause. Clear language on what you owe and what you receive if either party terminates mid-project. Work completed to date gets compensated. You receive all files produced to that point. Deposits for unstarted phases are returned or classified as a defined cancellation fee.

8. Hosting and code ownership

Hosting is often the last thing clients think about and one of the first things that causes problems. The conversation to have — before the project starts, not after launch — covers where the site lives, who controls it, and what happens when you want to move.

Your domain is non-negotiable. The registrar account must be in your name and tied to your email. A developer who holds your domain holds the most critical asset in your online presence hostage. If the relationship ends badly, they have leverage. Transfer it to your own registrar account before the project starts. Namecheap, Cloudflare, or Google Domains all work. It takes about 10 minutes.

Hosting: your account or managed. Two legitimate options exist. Either you set up your own hosting account (Hetzner, DigitalOcean, Cloudways, WP Engine if on WordPress) and the developer deploys to it, or they provide managed hosting at a monthly fee and handle server maintenance. Both work. Managed hosting means they handle SSL renewal, security patches, uptime monitoring, and backups, all of which require time and expertise. The fee is a fair trade. The key question: can you take your source files and leave? If yes, it's transparent. If a developer won't hand over your source code, that's the red flag, not managed hosting.

You should receive the code. At delivery, you get either a GitHub repository or a complete zip of all source files. Not an admin panel login. Not view access to a hosted copy. Actual source code that any developer can open, read, and extend without proprietary tools or credentials.

What else to keep control of. Beyond the domain and source files: the Google Search Console property (should be verified under your Google account), the Google Analytics property if applicable, any payment processor accounts, and any third-party API keys the site uses. A developer can be a delegate on all of these, but the account ownership should be yours.

For a complete checklist, see website ownership: what to keep control of. The Web Hosting page describes what ArdinGate's managed hosting tiers include (server maintenance, nightly backups, security patching, SSL, uptime monitoring) and what the exit process looks like.

9. SEO: what the developer handles vs. what's your job

SEO confuses hiring conversations more than any other topic because the word covers two completely different categories of work. One falls to the developer. The other doesn't.

Technical SEO is built into the site during development: page load speed, fast performance on mobile, correct HTTP response codes, signals that prevent Google from seeing duplicate pages, behind-the-scenes labels that tell Google exactly what your business is (for your homepage, service pages, FAQ content, and breadcrumb trails), the preview images and text that appear when your link is shared on social media, a complete list of every page on the site, clean server rules that tell search engines which pages to index, and a design that looks good and works on phones. This happens once at build time and should be in the standard deliverable. Verify it's in scope by asking specifically: what behind-the-scenes business labels will be added, will your page list go into Google Search Console, and what loading-speed scores are targeted on mobile.

Content SEO (keyword research, content strategy, topical clusters, backlink acquisition, ongoing blog content) is not a development task. When someone promises to "do your SEO," they usually mean the technical layer. That's fine, but the difference matters: the technical side is a one-time deliverable while content SEO is ongoing strategy. Ongoing content work needs someone who specializes in it. The two aren't interchangeable.

The SEO Setup service page describes the technical SEO layer included in a new ArdinGate build and when a standalone SEO audit on an existing site makes sense.

After launch, verify the work: run PageSpeed on mobile, check the Search Console coverage report to confirm all pages are being indexed. A developer who delivered clean technical SEO will have nothing to hide.

10. After launch: maintenance and ongoing support

Most don't think about post-launch maintenance until something breaks. Here's what will eventually need attention and how to plan before the site is down and you're scrambling.

PHP version upgrades. PHP releases new major versions regularly, and hosts drop support on schedules. When your host moves from PHP 7.x to 8.x, compatibility issues surface: deprecated functions, changed behavior in edge cases, library updates. Not complex work, but it needs someone who knows the codebase. On managed hosting, this is commonly handled by the host. On unmanaged hosting, it's your responsibility to notice and respond.

Security patches. If your site uses WordPress, a framework, or any packages, vulnerabilities get disclosed constantly. Automated scanners find unpatched versions within days of CVE disclosure. A managed hosting plan with active monitoring is worth the monthly cost if you're not watching yourself. A custom-coded site with no third-party dependencies has a much smaller attack surface—fewer documented vulnerabilities to exploit.

Content changes. Your team page changes when you hire. Service descriptions evolve with your offerings. Pricing updates when rates change. Someone handles this. Your options: a CMS for non-technical staff, a developer on retainer, or batching changes and paying project rates. All three work. Pick one before launch, not the first time you need a change and scramble.

Hosting migrations. Servers get deprecated. Data center prices shift. Hosts get acquired. Over a 5–10 year lifespan, you'll likely move to a different host. A developer who documented deployment and delivered clean source code can execute the migration. A proprietary platform has no migration path—you rebuild.

Performance audits. Google's ranking algorithms and page-speed requirements evolve. A site that performs well at launch may drift as requirements change or new formats become standard. An annual check (PageSpeed and Search Console on mobile) catches issues before they affect rankings.

The Website Maintenance plans describe ArdinGate's structured ongoing support: what's included at each tier, when a monthly retainer makes more sense than per-incident billing, and what "managed hosting" actually covers in practical terms.

11. Key takeaways

• Decide platform first, developer second. Custom hand-coded, WordPress, and page builders are fundamentally different products. Understanding which is right for your situation shapes every other decision.
• Own your domain and source files unconditionally. Your domain registrar account is yours. Your source code is delivered to you at launch. These are non-negotiable terms, and any developer who won't agree to them is not the right developer.
• A contract is not optional. It protects both parties. At minimum it needs scope definition, IP terms, revision rules, payment structure, and a termination clause.
• Low price and good value are not the same thing. The cheapest quote almost never represents the best outcome. Evaluate on portfolio quality, communication speed, technical specificity, and contract terms — then on price.
• Technical SEO is a build deliverable, not an ongoing service. It should be included in the initial build scope. Ongoing content SEO is separate work by a different type of specialist.
• Plan the post-launch maintenance model before launch. Whether it's managed hosting, a retainer, or per-incident billing, having a plan means you're never scrambling when something needs attention.
• The boutique or independent developer is often the best fit for small businesses. You get direct access to the person building the project, lower overhead baked into the price, and a developer with a professional stake in the outcome.