The questions that predict whether a web project goes well

1. Why the standard discovery call misses everything important

A typical developer discovery call goes like this: you describe what you're looking for, the developer describes their process and past work, you talk about a rough timeline and budget range, and then you get a proposal in your inbox. If the price looks reasonable and the portfolio is decent, you hire them.

Crucial questions often go unasked: code ownership, platform suitability, hosting-account ownership, scope creep, form security, and breakage six months after launch. Discovering answers afterward prevents using them in your hiring decision.

This guide is organized around the questions that surface those answers before you sign anything. They're grouped by category so you can work through them systematically. At the end of each question is what a good answer looks like and what answer should give you pause.

One important note before you start: the goal isn't to interrogate. Most of these questions are things a professional developer expects and is comfortable answering in detail. A developer who bristles at being asked about ownership, contracts, or technical decisions is showing you something just as clearly as one who answers with specificity and confidence. Both reactions are information.

2. Questions about code and domain ownership

Ownership questions are the most important category and the one clients most often skip. The answers determine whether you're building a portable digital asset or an expensive dependency on one developer's continued goodwill.

Who owns the code when the project is done?

Specify ownership contractually. In many places, freelancers retain ownership unless assigned; payment or hosted access alone doesn't transfer it. Require rights to host anywhere, change developers, and use the work freely.

Your agreement should include a clear line that hands ownership to you: everything built for your project becomes yours once you've paid in full. The developer may reasonably keep rights to their own reusable building blocks they've used on other projects too (that's normal), but the work built specifically for you should be yours outright.

Good answer: "Everything I build for your project becomes yours once it's paid for. I keep rights to my own reusable building blocks, but the work made for your project is yours outright, and it's spelled out in the agreement before we start."

Flag: "It lives on my server and you access it through your admin panel." Or any version of "we keep ownership of the code" without a clear, written license you've reviewed. If the actual files behind your site never transfer to you, you don't own what you paid for.

Will you register my domain in my name?

Register domains in your name/email and retain credentials. Developer-owned accounts give leverage in disputes and can cut off your online presence until costly, slow legal resolution. Small businesses face this regularly.

If your developer needs to connect your domain name to your website (pointing your domain at the right server, setting up your email, or proving to Google that you own the domain) they can do all of that with temporary access to your account. They don't need to own the account to set it up.

Good answer: "Your domain stays in your account. I can help connect it to your site, but the registration is yours and stays yours."

Flag: "I'll handle all of that setup for you" with no mention of whose name the registration ends up in. This is the most common way clients lose control of their online presence in a dispute.

Do I get a complete copy of all my site's files when it's handed over?

At delivery, obtain all actual site files and stored data in a form any skilled developer can use without proprietary tools/platforms. Hosted view-only access or a locked control-panel login is insufficient.

Portability tests ownership: clean files usable by another developer demonstrate control. "Proprietary" claims or warnings that taking files breaks the setup indicate the work was never yours.

Good answer: "Part of the launch handoff is a full delivery: all your site's files and a copy of its data if it has any. You can move to any host at any point."

Flag: "You can always request an export." The framing of requesting permission for your own data is a flag. Source file delivery should be a standard deliverable, not a favor extended on request.

3. Questions about platform and technical approach

The platform your site is built on affects load speed, security surface, maintenance burden, portability, and what the site can realistically do over the next five years. Most clients never ask about it and encounter the consequences long after they've paid.

What are you proposing to build my site on, and why that choice for my project specifically?

Evaluate plain-language reasoning tied to your needs, not technical depth. "I know WordPress" differs from recommending custom because you don't edit daily and it offers faster loading, better Google scores at your traffic level, and no add-on updates.

WordPress means theme/plugin compatibility and security upkeep across a dozen-plus packages, including add-on-specific vulnerabilities. Custom avoids that. Squarespace/Webflow provide no underlying files to take; leaving means restarting. Each can suit particular projects. Test whether the choice reflects yours.

Good answer: Specific reasoning tied to your project's requirements, content update frequency, traffic expectations, and budget constraints. A developer who can describe the tradeoffs in plain English has earned the recommendation.

Flag: "WordPress is the industry standard" or "everyone uses [platform]" with no connection to your specific situation. Using the same tool for every client regardless of fit is a sign of a developer who hasn't thought about your project.

Will the site load fast on a phone and pass Google's speed checks?

Google's three ranking-related checks measure main-content appearance, tap response, and layout stability. Mobile scores often suffer, especially with heavy WordPress themes/builders adding dozens of files.

Request commitments: Google pre-handoff tests targeting 90 desktop/70 mobile, not "fast." Better, test two or three live portfolio sites on mobile during the call. Confident developers welcome it.

Good answer: Specific mobile and desktop score targets with a commitment to test before handoff and share the results as part of the delivery package.

Flag: "It'll be fast," "we use [platform] and it handles performance," or any answer that doesn't include actual numbers and a process for verifying them.

Will you write the code by hand or use a page builder?

Ask directly: hand-built code is lean and portable to competent developers. Divi, Elementor, and Beaver Builder output tightly coupled, tangled code; leaving often requires a complete rebuild, affecting speed and maintenance.

This isn't an argument that page builders are always wrong. They can be the right tool for someone who needs to edit their own pages without a developer's help. But the tradeoffs should be discussed up front, not discovered later when you take a peek behind your own site and find it's an unreadable mess.

4. Questions about hosting and infrastructure

Hosting is often treated as an afterthought in the developer hiring conversation, but it has direct implications for your ongoing costs, your control over the site, and what happens if the developer relationship ends.

Who provides the hosting and what does it cost per month?

Some developers bundle managed hosting with their build and ongoing retainer services. Others hand off the site to your own hosting account. Both are valid arrangements with different tradeoffs. What isn't acceptable is ambiguity: you should know exactly what you're paying monthly for the infrastructure, who you're paying it to, and what that payment covers.

Itemize hosting separately from retainers/maintenance. Ask server type, physical location, and uptime guarantee. Specific answers demonstrate professional arrangements; "don't worry about infrastructure" asks for unevaluated trust.

Is the hosting account in my name or yours?

Is hosting registered to your legal name/payment method or a developer reseller account? Yours transfers cleanly; theirs controls the off switch when the relationship ends.

Good answer: "You have your own account with [hosting provider] in your name. I have admin access to configure and maintain it, but the account credentials are yours and you can revoke my access at any time."

Flag: "I manage all the hosting on behalf of my clients" or "the server is mine and I host multiple client sites on it." Neither is inherently wrong, but you need to understand the exit process clearly and have it in writing before you start.

What is the process for moving the site to a different host if I need to?

Ask about moving even if unplanned. Files/data → new host → domain repointing describes portable ownership. Complicated, expensive, or developer-dependent moves reveal built-in dependency.

5. Questions about process, revisions, and timeline

Process questions reveal whether the developer has run projects like yours before and has a repeatable system for managing them, or whether you'll be navigating the project largely on your own once work starts.

How are revision requests handled: included rounds or billed hourly?

"Unlimited revisions" sounds like client protection but often isn't. In practice, the developer will either quietly rush you toward sign-off to close the engagement, or the relationship eventually becomes strained because scope is being consumed without a defined end. Clear revision rounds with a defined change-order process are better for everyone.

Require revision rounds per phase, revision/scope-change definitions, and change-order hourly rates. Two design rounds are standard; three generous. "Unlimited" usually sells better than it works.

Good answer: "Two rounds of design revisions are included per phase. Functionality changes outside the original specification are billed at our change-order rate, which we agree on before starting any out-of-scope work."

Flag: "Unlimited revisions until you're satisfied." Without a scope definition, this creates a dynamic that frustrates either the developer or you.

What's a realistic timeline, and what usually causes delays on projects like mine?

A six-week estimate needs dependencies: final copy/images, stakeholder feedback, third-party integration setup, and board/partner/landlord approvals. Without these, a timeline is merely an appealing number.

Experienced developers identify delays, usually client content/feedback rather than development. If reversed, investigate. Ask timeline dependencies and how you can keep the project moving.

Good answer: "Three to six weeks from signed contract to launch, assuming content and images are supplied by week two and feedback rounds are turned around within 48 to 72 hours. If you have third-party integrations in scope, those can add time depending on setup complexity."

Flag: A specific timeline with no context, or "it depends" with no guidance on what questions to answer to get a range.

What does your project process look like from contract to launch?

You want a clear picture of the phases: discovery and planning, design or wireframing, development, content integration, review, and launch. What happens at each stage, what you're responsible for providing, what the developer delivers, and how approvals work. A developer who can walk you through this fluently has done it enough times to know where things usually get complicated.

This question also surfaces whether there will be a staging environment where you can review the full site before it goes live. Every professional build should include a staging review step. Skipping this stage (launching directly from development without a client review on a staging URL) costs you the ability to catch and fix issues before they're live.

Who else will be working on this project?

Subcontracted design, copy, or technical work is legitimate. Ask team arrangements and who controls quality. Your developer's contract remains accountable; subcontracting doesn't transfer legal responsibility to you, but dependencies should be clear.

6. Questions about pricing, contracts, and payment

Price questions are easy to ask but hard to interpret without context. Two quotes for a "five-page website" can differ by a factor of four and both be justified, because they're describing fundamentally different deliverables. The questions below help you compare what's being proposed.

Is this a fixed-price project or hourly billing?

Seek fixed fees for defined scope: developers absorb estimation overruns. Hourly marketing-site work transfers overrun costs to you without an agreed ceiling. Estimation is difficult; hourly billing shields developers from errors you fund.

Hourly or retainer billing is the right structure for open-ended ongoing work: monthly content updates, on-call support, evolving feature development where scope isn't defined upfront. For a discrete project with an agreed deliverable, fixed price is almost always better for you.

What's the payment schedule, and what are the milestones?

Payment schedules set incentives for both sides. A developer who takes 80% upfront has less urgency to push through the harder second half of the project. A client who refuses to pay until launch gives the developer no ability to plan their own cash flow. The right structure ties payment releases to specific, verifiable deliverables.

A common reasonable structure: 30 to 40% at contract signing to reserve the developer's time and begin work, a second payment at design approval or staging review, and the balance at launch. Each payment release is tied to something you've reviewed and approved, which keeps both sides accountable throughout the project rather than only at the beginning and end.

A 100% upfront payment before any work starts is never appropriate. Even a simple 50/50 split with no intermediate milestone is a structure with avoidable risk on both sides.

Is there a written contract, and what does it cover?

Always require a contract, regardless of size/familiarity: code ownership, scope/exclusions, revision limits/extra rates, payment milestones, key dates, post-launch support, and termination rights, including completed-work ownership and transfer format.

A developer who says a small or simple project doesn't need a contract is telling you something about how they handle disputes when they arise. Walk away.

What moves the price from the minimum to the maximum end of your range?

Initial ranges are reasonable before full scoping. Ask what raises/lowers price: it identifies controllable scope decisions and distinguishes consistent pricing from guesses about your means.

For custom PHP builds, ArdinGate starts at $1,200 for single-page builds and $2,800–$5,000 for multi-page business sites. What moves the number: page count, third-party integration complexity, whether the project includes a contact form only or a full booking or e-commerce component, the amount of custom design work versus structured page templates, and the scope of technical SEO deliverables.

7. Questions about security and data handling

Security questions don't come up in most developer hiring conversations because clients assume they're covered. They're often not, or they're handled inconsistently from project to project. Asking specifically signals that you know what to look for and expect it to be treated as a deliverable.

How are contact forms protected against spam and abuse?

Public forms need origin verification against forged submissions, short-window rate limits, and input cleanup before storage/email. These professional minimums prevent spam, phishing, and possible data tampering.

Good answer: "Every form checks that submissions are real, limits how often it can be sent to block spam floods, and cleans up the input before doing anything with it. Contact messages are emailed to you through a reliable delivery service rather than piling up in a database."

Flag: "I use a contact form plugin" without any specifics about what that plugin provides, or any answer that doesn't address the specific mechanisms used.

Is the security padlock included, and how is it kept active?

HTTPS/padlocks are mandatory for professional 2026 launches. Certificates expire, often yearly; lapses trigger effectively site-blocking browser warnings. Confirm inclusion, automatic renewal, and named monitoring responsibility.

If the developer is providing your hosting, keeping the padlock current should be part of that service. If you run your own hosting account, you'll need to make sure it renews itself automatically or that your hosting plan handles it.

What data submitted through the site is stored, and where?

For contact messages, booking requests, or other visitor input, ask where it goes: a database, email followed by disposal, or an outside service? If stored, what prevents attackers from extracting the database? Can the open internet reach it, or only your website?

These aren't paranoid questions. They're the difference between a site that follows responsible data handling and one that accumulates personal contact information in an unsecured table that hasn't been looked at since launch. If you're subject to any privacy regulations (CCPA, GDPR if you have EU visitors), the storage question has direct compliance implications.

Are admin paths and directory listings protected?

Require disabled directory listings, authenticated admin areas with rate-limited logins, and blocked direct access to configuration/include files. These basic hardening measures belong in standard scope.

8. Questions about SEO: what's included and what isn't

SEO creates more confusion in the developer hiring conversation than any other topic, because the word covers two completely different categories of work and most developers mean one of them when clients assume the other. Getting clarity on this before the project starts prevents significant disappointment after launch.

What technical SEO is included in the build?

Technical SEO helps Google find, understand, and trust pages: business/page labels, duplicate-prevention signals, submitted sitemaps, social preview images/text, mobile speed, and old-to-new address forwards preserving traffic. It supports rankings and sharing.

Build technical SEO once during development; later additions cost more and work less reliably. Confirm business-specific labels, Google sitemap submission, and mobile speed targets are included.

Good answer: A specific list of what they'll do with concrete targets. "We add the labels that tell Google what your business is and tag your FAQ pages so they can show up directly in search results, hand your site map to Google, stop duplicate-page confusion, and aim for 90-plus on computers and 70-plus on phones for speed."

Flag: "We do basic SEO" with no specifics. "Basic" is not a deliverable.

Do you handle ongoing content SEO, or is that separate?

Keyword research, strategy, topic clusters, links, and ongoing blogging are separate content-marketing work. Developers' "SEO" usually means technical setup. Hire a search-content specialist alongside or after development if ongoing strategy is needed.

The technical foundation and the content strategy are both necessary. They're just different services performed by different specialists. A developer who conflates them, or who implies their technical setup will produce organic traffic growth without an ongoing content investment, is overselling what a build can do.

9. Questions about third-party integrations

Most sites need forms, bookings, payments, customer-record connections, chat, or calendars. Complexity varies widely; poorly discussed proposal-stage integrations cause the most trouble.

What add-ons are in the plan, and which will you build versus drop in?

Distinguish native features, developer-written forms with reliable mail or integrated checkout, from external embeds such as Calendly, Google Maps, or chat. Native code belongs to the site; outside services add their own load, performance impact, and failure modes.

Neither approach is inherently wrong. Identify native versus external features individually: slow/unreliable widgets can hurt Google speed scores and introduce unexpected tracking/privacy concerns.

What happens if an outside service changes how it works after launch?

Email authentication, payment interfaces, and booking widgets change. Resulting failures can remain hidden until visitors submit/book. Ask who monitors these connections after launch and handles breakage.

This isn't about fault. It's about having a clear maintenance path. A developer with a managed maintenance retainer covers this automatically. A developer whose engagement ends at launch leaves you responsible for catching and reporting integration failures, with an hourly engagement to fix them.

10. Questions about accessibility

Web accessibility (building sites that work for people using screen readers, keyboard navigation, high-contrast modes, and other assistive technologies) is frequently skipped in developer hiring conversations because it feels niche. It isn't. ADA Title III lawsuits against small business websites are a documented legal risk, and basic accessibility compliance is standard professional practice for any build in 2026.

What accessibility standard does the site target?

Ask whether builds target WCAG 2.2 Level AA, the current benchmark commonly cited in small-business disability-access suits. Require specifics: organized code, screen-reader image descriptions, sufficient contrast, full keyboard access, and labeled buttons/links.

A developer who can answer this specifically is building with accessibility as a first-class consideration. A developer who says "the design will be clean and readable" is conflating visual design with technical accessibility. They're related but not the same thing.

Good answer: "The build aims for WCAG 2.2 Level AA. We keep the page code clean and well-organized, test the main paths through the site with a screen reader, make sure text colors are easy to read, and confirm the whole site works with a keyboard before launch."

Flag: Confusion between accessible design (good fonts, readable layout) and technical accessibility compliance. They are related but the technical layer requires specific, testable implementation.

Will there be an accessibility statement on the site?

Accessibility statements record compliance, limitations, and accommodation/reporting contacts. They demonstrate good faith and provide contact routes relevant to ADA compliance, without independently shielding liability. Useful for hospitality, healthcare, retail, and professional services.

11. Questions about post-launch support

After launch, email-rule or host-software changes can break forms/sites; prices, services, and team details need updates. Establish an affordable response path before these inevitable needs arise.

Is there a warranty period after launch?

Professional warranties commonly cover normal-use bugs free for 30 days after launch. After that month, fixes/updates are billable, usually hourly. Define the period explicitly.

Ask specifically: how long is the warranty period, what does it cover (bugs only, or also compatibility issues triggered by external changes to third-party services), and what is the response time commitment during that period. A 30-day warranty with a 48-hour response commitment is a reasonable professional standard.

How are content changes handled after the site is live?

Three options: a CMS adds build scope/cost but enables nontechnical updates; a monthly retainer handles requests within defined turnaround; per-request billing batches accumulated changes into projects.

All three are legitimate depending on how frequently you'll need changes and what you're willing to pay for the convenience of on-demand access. What you want to avoid is launching without a clear answer to this question and discovering after the fact that the developer charges emergency rates for anything because you didn't establish a support arrangement upfront.

What happens when the software your site runs on gets updated?

Hosts regularly retire software versions, potentially breaking unmaintained sites. Annual certificate renewal and component security patches also need ownership. Ask who monitors and handles these before failure.

Developer hosting should include this oversight. Self-hosting requires in-house expertise or a monthly developer arrangement. Paying an accountable monitor beats discovering three months of errors through visitor complaints.

12. How to evaluate the answers you get

Asking the questions is only useful if you know what to do with the answers. Web development has enough technical surface area that a developer can sound credible while describing an approach that will cause you problems in 12 months. The tests below let you verify answers in real time as well as listen to them.

Run a free speed test on one of their sites during the call

During the call, test a live portfolio URL at pagespeed.web.dev on mobile. Read flagged image delays and blocking external scripts, not just scores. Confident developers welcome scrutiny; dismissal or switching examples reveals how they handle real performance.

Take a peek behind one of their sites

Right-click a portfolio page's blank area → "View Page Source." Assess organization without understanding code: hand-built pages show clean structure/business labels; builders reveal repetitive styling, messy markup, and many blocking files. Even a glance provides clues; confident developers won't object.

Ask why they made a specific choice

Ask why this platform fits or how host upgrades are handled. You needn't grasp every detail; watch for specific, plain-language reasoning. Generic "standard approach" answers or subject changes suggest autopilot rather than project-specific judgment.

Cross-check the ownership answer with a practical scenario

Ask code ownership, then fifteen minutes later ask what a replacement developer needs in two years. Both should describe handoff files, new hosting, and domain repointing. Newly introduced hosting dependencies contradict simple ownership; resolve them before signing.

What they bring up before you ask

Experienced developers proactively explain contractual ownership, file/data delivery, business labels, and certificate renewal. Minimal answers only when prompted suggest inexperience or avoidance. Either warrants further due diligence before signing.

13. Key takeaways

• Ask who owns the code before anything else. The answer (and whether it's stated explicitly in the contract) determines whether you're building a portable asset or a dependency. Non-negotiable.
• Your domain must be registered in your name. Not the developer's, not a shared account. Your registrar, your email, your credentials. Before the project starts.
• Your hosting account should be in your name too. Or at minimum, you should have a clear, documented exit path that doesn't require the developer's cooperation to execute.
• Ask for the platform name and the reasoning behind the choice. The reasoning tells you whether the developer thought about your project specifically or is defaulting to their usual tool.
• Fixed price is almost always better than hourly for a defined-scope build. With a fixed fee, the developer absorbs estimation risk. With hourly billing on a bounded project, you absorb it.
• Security is a deliverable, not a default. Spam protection on your forms, a security padlock that renews itself, and locked-down behind-the-scenes areas — ask for these explicitly and confirm they're included.
• Technical SEO is a build deliverable, not an ongoing service. It should be built in from day one. Ongoing content SEO is a separate engagement from a different specialist. Clarify which one you're discussing before you sign.
• A post-launch plan is part of the build conversation. Warranty period, content update process, server maintenance, integration monitoring — these need clear answers before launch, not when something breaks.
• Specificity is the best signal across the board. Concrete answers tied to your project and backed by verifiable portfolio work are more valuable than any credential, platform badge, or years-in-business claim.