Complete Guide
The Complete Guide to Choosing a Web Developer for Your Small Business
What to look for, what to avoid, how pricing actually works, and how to make the right call — without getting burned.
In this guide
- Do you actually need a developer?
- Freelancer vs. agency vs. boutique developer
- Custom code vs. WordPress vs. page builders
- How web development pricing actually works
- Red flags when evaluating developers
- What belongs in the contract
- Hosting and code ownership
- SEO: what your developer handles vs. what's your job
- After launch: maintenance and ongoing support
- Making the decision
1. Do you actually need a developer?
Before you hire anyone, the real question is whether you need a custom website built by a developer or whether an off-the-shelf website builder would get the job done. Plenty of business owners hire developers when they didn't need to — and plenty use website builders when they actually needed a developer.
Here's the honest version: if your site is purely informational — name, what you do, contact info, maybe a photo gallery — and you're comfortable maintaining it yourself, Squarespace or a similar platform will work. For a basic online presence, a $16/month Squarespace plan is a legitimate option.
But "comfortable maintaining it yourself" is doing a lot of work in that sentence. The moment you need something that isn't covered by built-in templates — a custom booking flow, a client portal, a database-backed tool, payment processing with specific logic — you're either bolting on third-party plugins (which have their own limitations, pricing, and security surface) or you're calling a developer anyway to hack something into a platform that wasn't designed for it.
The bigger issue with website builders is what happens when you want to change hosting providers, move to a faster server, or hand the site off to someone else. You don't own the code. You're renting an opinionated platform. The moment you want to leave, you start over.
When to hire a developer: You want to own the code outright. You need features builders don't support. You're generating real traffic and want technical SEO and Core Web Vitals control. You've outgrown your builder and every customization is a workaround.
2. Freelancer vs. agency vs. boutique developer
Once you've decided you need a developer, the market breaks into three main buckets. They're not interchangeable.
Freelancers are individual contractors, often working across multiple clients simultaneously. The quality range is enormous — from a CS student charging $30/hour to a senior developer with 15 years of experience charging $150+/hour. The variance is high. Key risks are availability (one person = one point of failure), accountability (disputes are person-to-person, not entity-to-entity), and documentation (solo operators don't always write clean, documented code someone else can maintain later).
Agencies are teams — typically an account manager who handles communication, a project manager who coordinates internally, a designer, and one or more developers. The upside: staffed capacity, process, and organizational accountability. The downside: the person you meet in sales is rarely the person who builds your project. All the people who aren't directly writing code get baked into the price. Agency quotes often run 2–4x what a solo developer charges for identical scope.
Boutique developers are the middle path: typically one developer with a professional entity (LLC, proper contracts, defined deliverables). You're talking directly to the person building your project. The boutique model sacrifices raw capacity for directness — a solo developer can't run three enterprise projects simultaneously, but for the $2,800–$10,000 marketing site or web app that most small businesses need, the boutique is often the best fit.
The ArdinGate vs. Agency comparison breaks this down in more detail with a side-by-side look at what those differences mean for your specific project type.
3. Custom code vs. WordPress vs. page builders
"What platform are you building on?" is often the first question asked, and the answer matters more than most people realize.
WordPress powers roughly 40% of the web, which says something about its accessibility but shouldn't be read as a blanket endorsement. WordPress is a CMS designed around blog architecture, extended over 20+ years with plugins into something that handles almost anything — at a cost. Every plugin is a dependency, a security surface, and a performance hit. A WordPress site with 15 active plugins is a site with 15 external update cycles, 15 potential conflicts, and 15 different codebases that need to stay compatible with each other and with the underlying WordPress version. The WordPress vs. custom comparison goes into this in more detail.
The speed gap is real. A properly built custom PHP site consistently outperforms a plugin-heavy WordPress install on Core Web Vitals — not because the language differs, but because WordPress carries structural overhead (theme framework, plugin loader, multiple database queries per page load, Gutenberg) that a lean custom build doesn't.
Page builders (Squarespace, Wix, Webflow) are the "no developer required" option. They've improved significantly in recent years. The limitations are real though: you're renting the platform, not owning the code. Your hosting options are limited. When the platform raises prices or changes its infrastructure, your negotiating position is zero. Complex features always hit the ceiling of what the builder supports. The Custom vs. Page Builders comparison breaks down when the builder wins vs. when custom-code makes economic sense.
Hand-coded custom sites mean a developer wrote every file: the PHP router, HTML templates, CSS, contact form handler, database queries. Nothing is a black box. You can audit it, move it to any host, hand it to any developer. The tradeoff is cost: a hand-coded site takes more time to build than dropping content into a template. For a 5–15 page marketing site, the cost difference is often smaller than it looks — and the long-term maintenance overhead is substantially lower.
4. How web development pricing actually works
The pricing range in web development is genuinely confusing. Two quotes for "a 5-page website" might come back at $800 and $8,000. Neither number is wrong — they're describing different things.
The low end usually means: a developer will drop your content into a pre-built template and do minimal customization. Fast to do, fast to price. The result is functional, looks fine from a distance, and is maintained via the template vendor's update cycle.
The higher end usually means: a developer is writing the site from scratch — custom CSS, custom layout, technical SEO setup, Core Web Vitals optimization, schema markup. That takes real time, which costs real money.
Here's what actually drives the price:
- Custom vs. template: Building from scratch costs more than filling in a template. Both can look good. Only one will be unique and extensible.
- Page count and feature complexity: A 3-page informational site and a 12-page site with a client portal and pricing calculator are completely different scopes.
- Design included or not: If the developer is also doing design work, that adds time. If you're supplying final design files, it subtracts it.
- Copywriting: Most developers don't write copy. You'll hit launch day with placeholder text unless this is explicitly included or you supply it.
- Hosting and ongoing support: One-time build vs. build + monthly managed hosting vs. build + retainer for ongoing changes are different products with different pricing structures.
The Website Cost Estimator gives you a live range based on your specific selections — useful for calibrating expectations before any calls. The Pricing page shows ArdinGate's specific package tiers.
On hourly vs. project pricing: Project pricing is almost always better for you as the client. When the developer quotes a project fee, they absorb the risk of scope estimation. When they quote hourly, you absorb it. For defined scope, push for project pricing. For genuinely open-ended ongoing work, hourly or a retainer is appropriate.
5. Red flags when evaluating developers
You'll talk to a handful of developers before making a decision. Here's what to watch for.
They don't ask about your business goals. The first questions in a good discovery conversation should be about what you do, who your customers are, what you want visitors to do when they land on your site, and what's not working about your current setup. If the first question is "what colors do you like," you're talking to someone who's going to build a decoration, not a tool.
No contract, or a contract without an IP clause. The contract should say explicitly who owns the code when the project is done. "We'll host it for you" without a code delivery clause is a red flag — what happens when you want to move? Get it in writing that you receive the code in full on project completion.
Their portfolio is all templates or the same 3 clients. A WordPress developer who built 40 sites all on the same premium theme didn't build 40 sites — they deployed 40 copies of the same template. Ask to see the actual source code or ask specifically how the site was built.
They can't explain technical decisions in plain English. You don't need to understand every architecture decision, but a good developer can explain why they made the choices they made in terms that matter to you. "I'm using custom PHP because it lets you own and move the code freely and it's faster than a WordPress install for your use case" is better than just "I use PHP."
They registered your domain under their own account. Your domain registrar should always be in your name — that's non-negotiable. Managed hosting is a different story: paying a developer to run your site on their infrastructure (like WP Engine, Heroku, or a managed VPS) is a normal, transparent service arrangement. The test isn't who owns the server — it's whether you can take your source files and move them. If the answer is yes, you're fine. If a developer won't hand over your own code or domain, that's the red flag.
See how ArdinGate works for a process where these things are addressed before the contract is signed, not after.
6. What belongs in the contract
The contract doesn't need to be complex, but it needs to cover the things that cause disputes.
IP and code delivery: You own the code. Full stop. The contract should say all deliverables become your property on delivery and final payment. The developer can keep their own code libraries and internal tools, but the project code is yours.
Scope definition: Write down what's included — not "a website" but a specific list of pages, features, and integrations. The more specific the scope, the less ambiguous the change order conversation becomes.
Revision rounds: Define how many rounds of feedback are included. "Unlimited revisions" is a red flag — it usually means the developer will rush to get you to sign off, or they'll eventually resent the engagement. "Two rounds of design revisions, then changes beyond that are billed at the hourly rate" is clear and fair.
Timeline and milestones: Clear checkpoint dates mean you can evaluate progress without waiting until the end to discover something went wrong.
Termination clause: A clear description of what you owe (and get back) if the project is cancelled mid-way. Work completed to date is compensated; deposits for unstarted work are returned or defined as a cancellation fee.
7. Hosting and code ownership
Hosting is often an afterthought in the developer conversation, but it's where a lot of businesses get stuck.
You should own your domain. The domain registrar account should be under your name and email. If a developer registers the domain in their own account and holds it there, you're at their mercy if the relationship sours. Transfer the domain to your account before the project is done — this takes about 10 minutes.
Hosting: your account or managed. Either you have your own hosting account and the developer deploys to it, or the developer provides managed hosting at a monthly fee. Both are legitimate. Managed hosting means the developer handles server maintenance, security patches, and uptime monitoring — but if you leave, you need to migrate elsewhere. Always ask: "If I want to move to a different host or developer, what do I get and what's the process?"
You should get the code. On delivery, you get a repository (GitHub) or a zip file of all project files — not just a login to an admin panel. Actual source code. This lets any developer in the world maintain and extend your site.
The Web Hosting page describes what's included in ArdinGate's managed hosting tiers (server maintenance, backups, security patching, SSL, uptime monitoring) and what the exit process looks like.
8. SEO: what your developer handles vs. what's your job
SEO has two components: technical and content. A good developer handles technical SEO. No developer should promise to handle ongoing content SEO.
Technical SEO is built into the site: page speed, structured data (JSON-LD schema for your business type, service pages, FAQ), canonical URLs, Open Graph tags, sitemap, properly configured robots.txt, and correct HTTP response codes. These are things the developer does once during the build. You should verify they're in place — check PageSpeed Insights after launch, look at Google Search Console for coverage issues, inspect the page source for JSON-LD schema.
Content SEO — keyword research, content strategy, link building, ongoing blog content — is not a development task. A developer who promises to "do your SEO" is usually promising the technical layer and not much else. That's fine, but clarify it upfront. If you want ongoing content strategy, that's a separate engagement with someone who specializes in it.
The SEO Setup service describes the technical SEO layer included with a new ArdinGate build — structured data, meta configuration, sitemap, Core Web Vitals pass — and when a standalone SEO audit on an existing site makes sense.
A technically clean, fast site with proper structured data gives you the foundation. What happens above that depends on your content, your backlinks, and your market. A developer guarantees the technical foundation; ranking positions are not a deliverable anyone can honestly promise.
9. After launch: maintenance and ongoing support
Most business owners don't think about maintenance until something breaks. Here's what will eventually need attention.
PHP version upgrades. Hosting providers drop support for old PHP versions periodically. If your site was built on PHP 7.x and the host forces an upgrade to PHP 8.x, there will be compatibility issues to address. Not dramatic, not expensive, but someone needs to handle them.
Security patches. If you're on WordPress or any framework with public packages, security vulnerabilities get disclosed regularly. Unpatched sites get crawled by automated scanners and exploited. A managed hosting plan that includes security monitoring is worth the monthly cost if you're not monitoring this yourself.
Content changes. Someone has to update the team page when you hire, update service descriptions when your offering changes. Either you have a CMS that lets non-technical staff do this, or you have a developer on retainer, or you batch updates and pay project fees.
Hosting migrations. Servers get deprecated, prices increase. At some point, you'll want to move. A developer who documented the deployment can handle this without a full rebuild.
The Website Maintenance plans describe ArdinGate's structured ongoing support — what's included at each tier and when it makes sense to go on a retainer vs. pay per incident.
10. Making the decision
You've read through the landscape. Here's a simple framework for the actual decision.
Start with scope. Write down what you need: how many pages, what features, whether you need a CMS for ongoing content, what third-party tools you're integrating. This spec doesn't need to be polished — it just needs to exist so you can get consistent quotes that are actually comparing the same thing.
Calibrate with the cost estimator. Before any calls, run your spec through the Website Cost Estimator to set realistic expectations. If your budget is $1,500 and the estimate is $5,000, that's important to know before you start talking to developers.
Evaluate on portfolio and process, not price alone. The cheapest quote is almost never the right choice. Look at live work. Test sites on mobile. Check load times. Read the contract they're willing to use before you commit.
Questions to ask on the discovery call:
- Who specifically will build this project — you or someone on your team?
- What platform or stack are you proposing, and why that choice for my project?
- Who owns the code on delivery, and how do I receive it?
- What happens to the project if I want to switch developers in a year?
- Can I see a contract before I commit?
When ArdinGate is the right fit: your budget is in the $2,800–$8,000 range, you want hand-coded PHP with no framework or WordPress overhead, you value direct communication with the developer doing the work, and you want to own the code outright. Reach out to start the conversation — if it's not the right fit, you'll get an honest answer about that rather than a proposal you shouldn't take.