How to Hire a Web Development Agency Without Getting Buried in Change Orders

Can you walk me through the Git commit history of a recent project and explain three specific technical decisions you made along the way?

Why it matters: Template-heavy shops struggle with this because the meaningful technical decisions were made by the theme author, not by them. Agencies doing real engineering can talk through framework choice, caching strategy, and data-model trade-offs in concrete terms.

Strong answer: They open a real repo, walk through commits, and explain choices like why they used Next.js over a static framework, where they cached, how they structured the CMS schema, and which plugins they avoided as custom code instead.

What specific Lighthouse and Core Web Vitals targets will you guarantee, and what's your remediation process if we miss them at launch?

Why it matters: Site speed has a direct relationship with conversion at meaningful traffic, and agencies without performance guarantees deliver whatever performance falls out of their default stack.

Strong answer: They commit in writing to a mobile PageSpeed threshold and named Core Web Vitals targets (LCP and INP), describe how they'll measure (lab and field via Chrome User Experience Report), and define what remediation looks like if numbers miss.

How do you handle WordPress core and plugin updates after launch, and can you show me the staging-to-production update workflow?

Why it matters: Plugin and core updates routinely introduce regressions on WordPress sites, and agencies without an update protocol either avoid updates (creating security debt) or push them blind (creating outages).

Strong answer: They run updates on staging first, have automated regression checks for critical paths, document rollback procedures, and require client approval before production updates rather than treating it as background maintenance.

If your lead developer rolls off mid-project, how do you specifically maintain continuity, and what documentation standards do you enforce?

Why it matters: Mid-project turnover is common at agencies, and undocumented codebases force either an expensive restart or premium-rate cleanup. The risk compounds on long projects.

Strong answer: They name a backup developer who's already been pair-programming or reviewing PRs, point to written documentation standards (READMEs, ADRs, in-code comments), and describe the overlap period before the lead rolls off.

What's your change-request policy, and how do you specifically distinguish between bug fixes and scope additions?

Why it matters: Loose change-order language is the single most common source of overrun on web projects. Agencies that won't define the line in writing tend to draw it generously in their own favor mid-project.

Strong answer: They show a contract template with defined scope inclusions, a written rule that bugs are fixed at no charge, a published change-order rate, and a cap or approval threshold for cumulative change orders.

Can you show me a current client's staging environment and walk me through your weekly progress review process?

Why it matters: Agencies that don't share work in progress are typically hiding either a slow start or unresolved technical issues. Weekly visibility is what allows mid-flight course correction without a budget reset.

Strong answer: They open a real staging URL (with permission), describe their weekly demo cadence, walk through how they track feedback, and show the project portal or issue tracker their other clients actively use.

What happens if you miss the agreed launch date, and how do you coordinate with our marketing calendar?

Why it matters: Launch slip cascades into coordinated campaigns, paid spend, and product announcements. Agencies that don't take a position on date risk are effectively saying the slip will land entirely on you.

Strong answer: They build buffer into the schedule explicitly, accept some form of penalty or fee adjustment for material slip, and ask early about marketing dependencies rather than treating launch as a purely engineering milestone.

How do you test integrations with our CRM, email, and payment stack at realistic data volumes before launch?

Why it matters: Integration code that works against ten dummy records can fail predictably against thousands of real ones. Post-launch integration breakage is one of the most painful failure modes because it hits both revenue and operations.

Strong answer: They use sandbox environments for the named tools (Salesforce, HubSpot, Mailchimp, Stripe), run load tests against representative volumes, and have written failure procedures for what happens if a sync breaks at launch.

Your quote mentions content migration. Exactly how many pages and posts does that include, and what's the per-page cost above the included count?

Why it matters: Content migration is one of the most common scope-mismatch line items. A nominal page count in the quote, paired with a much larger real catalog, becomes a substantial mid-project surprise.

Strong answer: They name a specific included page and post count, describe automated migration tooling for larger catalogs, and quote a fixed per-page rate for content above the included threshold rather than negotiating it later.

How do you ensure zero data loss during content migration, and what's your rollback procedure if the migration goes wrong?

Why it matters: Losing years of blog or product content during migration is hard to recover from, and migrations without explicit verification routinely leave orphaned URLs, broken images, or missing metadata.

Strong answer: They take a full database backup before migration, run an automated content audit to compare source and destination, follow up with a manual verification checklist on a sample, and have a tested rollback path.

What training do you provide for our content editors, and can you show me sample documentation from another client?

Why it matters: Generic CMS tutorials don't help your team use the custom blocks, components, or content models you paid to build. Without training, simple edits become recurring billable requests.

Strong answer: They show client-specific video walkthroughs, written runbooks for common edits, and post-launch support coverage for content questions during the first month or two.

What's your guaranteed response time for site-down emergencies, and who specifically handles after-hours issues?

Why it matters: Site downtime on a transactional or lead-generation site has a direct revenue cost, and agencies without a named on-call process default to whoever happens to be online.

Strong answer: They commit to a named response window for site-down events, share a 24/7 escalation contact, and describe the on-call rotation rather than pointing to a shared inbox.

If our site gets compromised by malware or a vulnerability, what's your cleanup process and response time?

Why it matters: WordPress and other CMS-heavy stacks are routine targets, and cleanup without an established incident process can stretch for weeks while the site is offline or visibly compromised.

Strong answer: They include security monitoring, define an incident response SLA, walk through restore-from-clean-backup procedures, and have written examples of past incident handling.

Can you show me your backup and disaster recovery process, and how quickly can you restore from a complete failure?

Why it matters: Untested backups are common, and a real failure scenario is exactly the wrong moment to discover whether the recovery path actually works.

Strong answer: They run frequent automated backups, perform quarterly DR exercises against a non-production environment, define a recovery time objective in writing, and document the runbook in a place the client can access.

What's included in your ongoing maintenance retainer, and what specifically triggers additional charges?

Why it matters: Maintenance retainers with vague scope quietly become a way to bill hourly for work that the original retainer should have covered, with the client unable to push back without specifics.

Strong answer: They list what the retainer covers (core and plugin updates, security monitoring, minor content edits), define what counts as out-of-scope, and publish an hourly rate for those items rather than leaving it informal.