Start with ownership: who actually holds the keys when this is done?
This is the question most contractors skip, and it's the one that bites them two years in. Ask directly: when the build is finished, do you own the code and the domain outright, or does the developer (or their platform) hold the account the site lives in? A lot of "custom" builds are actually built inside a page-builder platform, a WordPress install managed by the agency's own hosting, or a proprietary CMS the developer controls. You get a login. You don't get the site.
That distinction matters the day you want to switch vendors, add a feature nobody else wants to touch, or the developer stops answering the phone. If you don't own the code and the domain, you are renting your own storefront. A developer who hands you the full codebase, on your own hosting account, has nothing to hide and nothing to hold over you. That's the standard to hold every quote to.
Practically, this means asking two follow-up questions before you sign anything: "Whose Cloudflare (or hosting) account does this live on, mine or yours?" and "If I want to leave in a year, what do I walk away with?" A shop that hands you a zip file, a git repo, and your own hosting login passed the test. A shop that gets vague, or quotes you a "transfer fee," did not.
This isn't paranoia, it's math. A site is the most expensive single piece of marketing infrastructure most contractors buy, and it's also the piece most often built on rented ground. Owners who've been through a bad vendor split already know the pattern: the developer goes quiet, the hosting invoice keeps arriving, and getting the files released turns into a negotiation with someone who has no reason to cooperate. Structuring ownership correctly at the start closes off that opening before it ever becomes a problem.
- Get the answer in writing before deposit, not after final payment.
- Ask what happens to the domain registration, not just the site files.
- If they use a proprietary builder (drag-and-drop platforms, some "managed WordPress" setups), assume you don't own it unless they prove otherwise.
- Confirm you'll get admin-level access to the hosting account itself, not just an FTP drop of files.
Custom code or WordPress? Know which one you're actually buying
Most contractor sites quoted as "custom" are WordPress with a theme and a page builder stacked on top. That's not wrong for every business, but it's a different product than hand-coded, and it comes with different math. WordPress runs on plugins for almost everything: forms, SEO, speed, security, the booking widget. Each plugin is another piece of code that can conflict, slow the site down, or get hacked. Contractors who've been through a WordPress site getting defaced or de-indexed after a plugin vulnerability know exactly what this costs in downtime and reputation.
Hand-coded static sites skip that surface area entirely. No plugin stack means no plugin vulnerabilities, no update treadmill, and no mystery slowdown after the fifth plugin gets added. The tradeoff: every custom feature takes developer time instead of a plugin install, so it can cost more up front for the same feature set. For a contractor whose site is core lead-gen infrastructure, not a hobby project, that tradeoff usually favors custom code once you count the cost of a slow or compromised site in lost calls.
Ask any developer you're vetting to name their stack plainly: "Is this WordPress, a page builder, or hand-coded?" If they dodge the question or use "custom" to mean "custom WordPress theme," that's useful information. Neither answer is automatically wrong for every business, but you should know which one you're paying for and why, and the price should reflect the actual build, not the marketing term.
| Factor | WordPress + plugins | Hand-coded / static |
|---|---|---|
| Plugin attack surface | Grows with every plugin | None |
| Update maintenance | Ongoing, recurring | Minimal |
| Speed ceiling | Capped by plugin bloat | Under 2 seconds achievable |
| Cost per custom feature | Often lower (plugin exists) | Higher (built by hand) |
Make them prove the speed claim, not just say it
Every developer says their sites are fast. Few will commit to a number. Under 2 seconds, anywhere in the US, is a testable claim: you can run any live site they show you through a free Core Web Vitals tool right there in the meeting and watch the load time. If a developer won't let you test a real example, or their examples run four, five, six seconds on a mobile connection, that's the answer to how the rest of your build will go.
Speed isn't a vanity number. A contractor whose emergency-service page loads slow on a phone in a driveway with two bars of signal loses that call to whichever competitor's site loaded first. Google also uses load speed as a ranking signal, and AI answer engines increasingly favor sites that load clean and fast enough to crawl efficiently. Slow is a cost you pay twice: once in lost calls, once in lost visibility.
What causes slow contractor sites, almost every time: unoptimized images, a stack of plugins each adding their own script, page-builder bloat that ships megabytes of unused CSS and JS, and hosting that wasn't built for it. Hand-coded sites on edge-network hosting (Cloudflare and similar) sidestep most of this by default, because there's no plugin stack generating the bloat in the first place.
"Anywhere in the US" matters as much as the number itself. A site hosted on a single origin server can test fast from the developer's office and load slow for a homeowner three states away. Edge hosting serves the site from a location near the visitor, not from wherever the server happens to sit, which is why the same load-time commitment has to hold whether the visitor is in Seattle or Orlando. Ask specifically how they achieve that, not just whether they promise it.
- Ask to see three live sites they built, tested on your own phone, on your own connection.
- Ask what happens to load time as you add pages, photos, and forms over time. It shouldn't degrade.
- Get the speed commitment in the proposal, not just the sales call.
- Ask how the site is hosted and whether load time holds up for visitors outside the developer's home region.
The integration test: can they actually connect to the software you run on?
A pretty site that doesn't talk to your business tools is a brochure, not equipment. Before you hire, list every tool the site needs to touch: your CRM or field service platform (ServiceTitan, Jobber, Housecall Pro, or whatever you run), your call tracking number, your booking or scheduling widget, your review platform, your payment processor if you take deposits online, and your forms provider. Then ask the developer, one by one, whether they've wired that specific tool before, or whether they're proposing to figure it out on your dime.
This is where a lot of "we do integrations" claims fall apart. Wiring a contact form to send an email is not the same skill as wiring a booking widget to write directly into your CRM's job queue, or wiring call tracking numbers so every source gets attributed correctly, or building a webhook that fires when a lead form submits so it lands in your pipeline instead of an inbox nobody checks. Ask for a specific example: "Show me a site where you connected the booking form to a CRM," not "do you do integrations."
The other half of this is what happens after launch. Software updates its API. A field service platform changes its webhook format. Ask who owns fixing that when it breaks: is it covered, is it a support retainer, or are you on your own once the invoice is paid? A developer who hands you working code with no plan for the day an integration breaks has handed you a ticking maintenance bill.
Attribution is the integration owners feel most directly in the wallet. If every lead source (organic, paid, a truck wrap, a referral) routes through the same generic phone number, you're guessing at what's actually generating calls. Dynamic call tracking wired into the site solves that, but only if it's set up correctly and tied back into whatever platform tracks your jobs. Ask the developer to walk you through exactly how a call from the website gets attributed and where that data ends up.
If the answer to any of these integration questions is a shrug or a promise to "look into it," that's a signal the build will be figured out live, on your budget, instead of executed from experience.
Read the contract for these three traps before you sign
Most contractor site disputes trace back to something that was never written down, or was written down in language nobody read closely. Before you sign, look for these three traps specifically.
- Hosting lock-in. Does the contract put the site on the developer's hosting account, with a monthly "hosting fee" that's really a hostage fee? Your own account, your own bill, is the clean version.
- Vague scope on integrations. "Includes contact form" is not the same as "includes booking integration with [your CRM]." Get every integration named specifically in the scope, not bundled into a catch-all "website functionality" line.
- No defined handoff. What exactly do you receive at project close: source files, admin credentials, domain registrar access, a walkthrough? If the contract doesn't spell it out, assume you'll be negotiating for it after you've already paid.
Ask for the contract before the deposit, read the deliverables section twice, and don't accept "we'll figure that out" as an answer to what you receive when the project is done. A shop that's proud of its handoff will put it in writing without being asked twice.
It's also fair to ask what a rebuild or migration looks like if you're coming off an existing WordPress site or an old brochure site. A straight lift-and-shift of bad code isn't a rebuild, it's a repaint. The right answer involves auditing what's actually there, keeping what works (rankings, existing content that's earning traffic), and rebuilding the engineering underneath it, not starting your search visibility over from zero.
Payment structure is worth reading closely too. A deposit up front is normal. A contract that front-loads nearly all the money before any working build exists leaves you no recourse if the project stalls or the work doesn't match what was promised. Milestone-based payments, tied to actual deliverables you can see and test, protect you the same way a draw schedule protects a homeowner on a renovation.
Check the portfolio the right way: live sites, not screenshots
A portfolio page full of static screenshots tells you almost nothing. Screenshots can't show you load time, they can't show you whether the site still works six months after launch, and they can't show you whether the "contractor sites" in the portfolio are actually other trades or just stock templates with a logo swapped in. Ask for live links, not images, and ask specifically for sites built for contractors in trades similar to yours: roofing, HVAC, plumbing, electrical, landscaping, whatever's closest to your business.
Once you have live links, put them through the same test you'd put your own site through. Load them on your phone on a real connection, not the office WiFi. Check whether the phone number is click-to-call. Check whether there's a form, and whether it actually looks wired to something (not just a mailto link). Look at how many pages the site has, whether the content reads like it was written for that specific trade or feels generic enough to belong to anyone.
Ask how long those sites have been live and whether the developer still supports them. A site that launched eighteen months ago and is still fast, still functioning, and still gets a maintenance response from the original developer tells you more than any pitch deck. A portfolio full of sites that launched in the last three months, with no examples that have survived a year, means you can't yet know how the work holds up.
- Ask for three to five live links in trades close to yours, not a slideshow.
- Test click-to-call and forms yourself, in the meeting, on your own phone.
- Ask how old the oldest live example is and whether it still performs.
Who this fits and who should look elsewhere
A hand-coded, integration-wired rebuild is the right call for an established contractor who already has call volume, already runs on a CRM or field service software, and has been burned by a slow, hacked, or hostage site before. If your current site is fine but invisible in search, that's a different problem: a rebuild won't fix a ranking problem, and the SEO and Local SEO silos are where that work lives.
If you're a brand-new business with no existing customer flow to protect, a simpler, faster, cheaper build might be the smarter first move, with the custom rebuild coming once you know what the business actually needs from the site. And if your priority is showing up in ChatGPT and AI Overviews specifically, the build quality matters (clean code crawls better) but that's an AI-search visibility play layered on top of the build, not a substitute for it.
The honest version of this: don't rebuild a site that's working just because a developer talked you into a redesign for its own sake. Rebuild when the current site is costing you calls, costing you ownership, or can't talk to the tools running your business. Those are testable, not aesthetic, reasons.