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.

The problem is that the questions predicting whether a project goes well almost never come up in that conversation. You don't ask who owns the code after the project ends, what platform they're proposing and why it fits your situation, whether your hosting account is in your name, how the contract handles scope creep, what the security posture is on form submissions, or what happens six months after launch when something breaks. By the time you find out the answers to all of those, it's too late to factor them into your 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?

This should be spelled out clearly in your agreement. Here's the catch most people don't know: in a lot of places, a freelance developer legally keeps ownership of what they build unless the contract says otherwise. Paying them doesn't automatically make it yours. "We'll host it for you" is not the same as ownership. You paid for the work; you should own the result, with the right to host it anywhere, change it with any other developer, and use it however you want without asking permission.

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?

Your registrar account must be in your name, tied to your email address, with you holding the login credentials. A developer who registers your domain under their own account holds your entire online presence as leverage in any future dispute. If the relationship ends badly, you can be effectively cut off from it until the situation is legally resolved. This process takes time and costs money you shouldn't have to spend. This isn't theoretical; it happens to small business owners regularly, and the recovery process is miserable.

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 project delivery, you should receive a complete copy of all the files your site is made of, plus a copy of its data if your site stores any. Not view-only access to a hosted copy. Not just a login to some control panel locked to one company's platform. You need the actual files, in a form any skilled developer can open, understand, and work on without special tools or being tied to one particular platform.

This is the single best test of whether a developer's work is portable. A developer who can hand you a clean set of files you could give to any other developer is showing you the work is genuinely yours. A developer who hesitates here, says the code is "proprietary," or claims you'd "break the setup" by taking the files is telling you the work was never yours to begin with.

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?

You don't need to evaluate the technical answer in depth. You need to evaluate whether the developer can explain the reasoning in plain language and whether that reasoning is connected to your situation. "I always use WordPress because it's what I know" is fundamentally different from "I'm proposing a hand-built site because you don't need to edit your own pages day to day, and a lean custom build will load faster and score better on Google's speed checks than a WordPress install at your traffic level. Plus, there's no pile of add-ons to keep updated."

The platform decision has real long-term implications. WordPress carries ongoing maintenance overhead: theme updates, plugin compatibility cycles, security patches for each of the dozen or more packages a typical install runs, and exposure to WordPress-specific security holes when any one of those add-ons has a bad update. A hand-built custom site has none of that by design. Squarespace or Webflow mean you never receive the actual files behind your site because there aren't any to hand over — when you leave the platform, you start completely over. Each option is the right answer in some situations. What you're testing for is whether the developer has thought about your project specifically.

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 runs a set of page-speed and stability health checks on every site, and they cover three things: how fast your main photo or headline shows up on screen, how quickly the page responds when someone taps a button, and whether the page jumps around while it loads. These checks factor into where you rank in search results, and the phone scores are where most small business sites fall short, especially ones built on heavy WordPress themes or drag-and-drop page builders that pile on dozens of extra files.

Ask for numbers. "It'll be fast" is not a commitment. "We run Google's free speed test before handoff and aim for a 90 or above on computers and 70 or above on phones" is a commitment. Even better: ask to see the speed-test scores of two or three live sites in their portfolio, tested on a phone right now during the call. A developer who knows their work will welcome this.

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?

This is worth asking directly because the answer has real consequences for speed, portability, and how easy the site is to maintain later. A hand-built site produces lean, clean work that any competent developer can pick up. A drag-and-drop page builder like Divi, Elementor, or Beaver Builder produces a tangled mess that's tightly locked to that one platform. Switching away from it later often means rebuilding the entire site from scratch.

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.

If the developer provides hosting, ask what the monthly cost is explicitly stated as a line item, separate from any ongoing maintenance or retainer work. Ask what kind of server runs the site, where it's physically located, and what guarantee you get on how often the site stays online. A developer who can answer those specifics has set up a professional arrangement. One who says "I handle the infrastructure, don't worry about it" is asking you to trust a situation you haven't evaluated.

Is the hosting account in my name or yours?

If you are on hosting the developer provides, ask specifically whether the account with the hosting provider is registered to your legal name and payment method, or whether it's a reseller slot billed through the developer. The difference matters when the relationship ends: an account in your name transfers cleanly. An account billed through the developer means the developer controls the off switch.

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?

Even if you don't plan to move hosts, ask this question. The answer tells you whether you have real control over the site. A developer who describes a clean move (you take your site's files and a copy of its data, set up a new host, point your domain name at it—done) is describing a portable asset you own. A developer who makes moving sound complicated, expensive, or impossible without their involvement is describing a dependency they've built into your situation.

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.

What you want is a specific number of included revision rounds per phase, a clear definition of what counts as a revision versus a scope change, and a defined hourly rate for change orders so you know what additions will cost before you request them. Two rounds of design revisions is a typical professional standard. Three rounds starts to feel generous. "Unlimited" is usually a sales talking point, not a sustainable policy.

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 number alone isn't useful. A developer who gives you a six-week estimate without context is giving you a number they think you want to hear. The timeline depends on specific factors, many of which are on your side: when you can supply final copy and images, how quickly you and any other stakeholders can turn around feedback, whether any third-party integrations are in scope that have their own setup timelines, and whether any approval layers (a board, a partner, a landlord) need sign-off before content is finalized.

A developer who has run enough projects will know exactly where time most often gets lost. The answer is often "waiting on client content and feedback," not "the development took longer than expected." If the answer is reversed, pay attention. Ask what the timeline depends on and what you can do on your end to keep the project on schedule.

Good answer: "Six to eight 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?

Many independent developers subcontract design work, copywriting, or specific technical components. There's nothing wrong with this, but you should know about it. Ask whether the developer works alone or has a team or regular subcontractors, and if so, who is responsible for quality control on work that isn't done directly by the person you hired. Your contract is with the developer you hired; their subcontractor arrangements don't transfer legal accountability to you, but you should understand the dependency structure you're actually working within.

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 actually being proposed.

Is this a fixed-price project or hourly billing?

For a defined scope, push for a fixed project fee. With a fixed price, the developer absorbs the risk when their time estimates are off. With hourly billing, you absorb it. An hourly engagement for a straightforward marketing site that takes longer than expected transfers the entire overrun cost to you, with no agreed ceiling to stop it. This isn't hypothetical — scope and time estimation are hard problems, and the developer who bills hourly is insulated from the consequences of an underestimate in a way that you are not.

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, for every project, regardless of size or how well you know the developer. A contract should explicitly cover: who owns the code at delivery, what is and isn't in scope, how many revision rounds are included and at what rate additional ones are billed, the payment schedule with milestone definitions, a timeline with key dates, post-launch support terms, and what happens if either party terminates the engagement before completion — including who owns the work completed to date and in what form it transfers.

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?

Most developers give a range rather than a fixed price at first contact, which is reasonable — they don't know your full scope yet. But asking what specifically drives the number higher or lower is useful for two reasons. First, it helps you understand what scope decisions you have control over. Second, it tells you whether the developer has a consistent pricing model or is adjusting the number based on what they think you can afford.

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?

Every contact form on a public-facing site should have a few basic protections: a check that the form was actually filled out on your site and not faked by a bot, a limit on how many times it can be submitted in a short window so spammers can't flood it, and cleanup of whatever someone types in before it's stored or emailed to you. Without these, your contact form becomes a doorway for spam, phishing, and in some cases real tampering with your data. These aren't fancy or unusual requirements — they're the bare minimum any professional should build into a form.

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 actually provides, or any answer that doesn't address the specific mechanisms used.

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

The little padlock in the address bar — the thing that turns your address into "https" and tells visitors the connection is secure — is non-negotiable for any website in 2026. Every professional build should launch with it active. The part that matters more is keeping it active: these security certificates expire, often once a year, and one that lapses makes browsers throw up a scary warning that basically takes your site offline. Ask whether the padlock is included, whether it renews itself automatically (it should), and who's responsible for keeping an eye on it.

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?

If your site accepts contact form messages, booking requests, or any other visitor input, ask specifically: is that information saved in a database, emailed to you and then thrown away, or passed along to an outside service? If it's saved in a database, what stops an attacker from tricking that database into handing over everything in it? And can the database be reached from the open internet, or only by your own 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?

Ask whether directory listings are disabled (so visitors can't browse your server's file structure at any URL without an index file), whether any admin interfaces are protected by authentication and rate-limited login, and whether the server configuration blocks direct access to configuration and include files. These are basic server hardening practices that should be in the standard setup of every project, not extras you negotiate for.

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 is the behind-the-scenes groundwork built into your site so Google can find it, understand it, and trust it: hidden labels that tell Google exactly what your business is and what each page covers, a signal that stops Google from seeing duplicate versions of the same page, a map of all your pages handed straight to Google, the right preview image and text when someone shares your link on social media, fast loading on phones, and old web addresses that automatically forward to the new ones so no traffic gets lost. Done right, all of it makes your site easier for Google to rank and nicer to share.

This is a one-time job done correctly while the site is being built. It should be part of any professional custom build. Bolting it on after launch costs more and works less reliably than baking it in from the start. Confirm it's included by asking specifically: what behind-the-scenes labels will you add for my type of business, will you submit my site map to Google, and what phone speed score are you aiming for?

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, content strategy, topical cluster development, link building, ongoing blog content publication — none of this is a development task. It's a separate ongoing marketing engagement with someone who specializes in search content strategy. When a developer promises to "handle your SEO," they almost always mean the technical layer. That's fine and appropriate, but if you need an ongoing content SEO strategy you should be looking for a content SEO specialist in addition to, or after, the developer engagement.

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 small business websites need at least one add-on beyond plain pages: a contact form that sends email, a booking system, a payment processor, a connection to your customer records, a live chat box, or an event calendar. These add-ons vary enormously in how complicated they are, and the ones that go wrong most often are the ones nobody talked about clearly during the proposal stage.

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

There's a meaningful difference between an add-on the developer builds and one they just drop in from somebody else. A built-in add-on — a contact form that sends mail through a reliable delivery service, a payment checkout built right into your site — is part of your own site that the developer writes and owns. A drop-in — a Calendly booking widget, an embedded Google Map, an outside live-chat box — pulls a feature in from another company's service, with its own loading time, its own effect on your speed, and its own ways of breaking.

Neither approach is inherently wrong, but you should know which is which for each add-on in your project. Embedded widgets from slow or unreliable outside services can drag down your page speed and hurt your Google speed scores. They can also bring in privacy and tracking concerns you didn't anticipate. Ask plainly: for each add-on in the plan, will this be built into the site directly or pulled in from somebody else's service?

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

The outside services your site connects to change over time. Email delivery services change their login rules. Payment processors retire old ways of connecting. Booking platforms change how their widget plugs in. When that happens, your site can break in ways that aren't obvious until a visitor tries to fill out a form or finish a booking and can't. Ask the developer who's responsible for keeping an eye on these connections after launch and what happens when one breaks.

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?

WCAG 2.1 AA is the current benchmark for web accessibility and the standard most commonly cited in disability-access lawsuits against small business websites. Ask whether the build aims to meet WCAG 2.1 AA and what specifically is done to get there: clean, well-organized page code, a written description on every image so screen readers can read it aloud, text colors with enough contrast to be easy to read, the ability to use the whole site with just a keyboard, and labels on buttons and links so visually impaired visitors know what each one does.

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.1 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?

An accessibility statement documents your site's current compliance level, any known limitations, and how users can request accommodations or report issues. It isn't a legal shield on its own, but it demonstrates good faith and gives users a contact path — both of which matter in the context of ADA compliance. If you're in an industry that serves a broad public audience (hospitality, healthcare, retail, professional services), this page is worth having.

11. Questions about post-launch support

Something will need attention after your site goes live. A form stops working because an email service changed its rules. Your host updates the underlying software the site runs on and something breaks. You need to update your pricing, add a new service, or add a team member. The question isn't whether these things will happen — it's whether you have a clear, affordable path to handling them before they arise.

Is there a warranty period after launch?

A professional developer includes a defined warranty period — typically 30 days — during which bug fixes are covered at no additional charge. This is a standard professional commitment: if I built something and it breaks in normal use within a month of launch, that's on me to fix. After the warranty period, any bug fixes or updates are a billable engagement, usually at an hourly rate.

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?

You have three realistic options. First, a CMS (content management system) so a non-technical team member can make changes without developer involvement — this adds scope and build cost, but reduces ongoing dependence on the developer for routine updates. Second, a monthly maintenance retainer where you submit change requests and they're handled on a defined turnaround schedule. Third, per-request project billing, where you batch changes and submit them when they accumulate enough to justify a billing conversation.

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?

The behind-the-scenes software that powers websites gets new versions on a regular schedule, and hosts stop supporting the older ones. When your host moves your site to a newer version, an older site can break if nobody updated it to keep up. The security padlock renews each year. Security fixes for the building blocks your site is made of need to be applied. Who's responsible for watching for all this and handling it before it becomes a problem?

If the developer is providing your hosting, this should be covered as part of the service. If you run your own hosting account, you need either someone technical in-house or a developer on a monthly arrangement who watches for it and responds when it matters. Finding out three months after one of these updates that your site has been throwing errors — because visitors finally started complaining — is a bad day. Having someone responsible for catching it first is worth the cost.

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 real problems in 12 months. The tests below let you verify answers in real time, not just listen to them.

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

Go to pagespeed.web.dev, paste in the address of a live site from their portfolio, and run the phone test while you're still talking. The overall score isn't the only thing to look at — read the specific notes the test gives you. If it flags that the main photo takes too long to show up, or that a handful of outside scripts are holding up the whole page from appearing, that's what this developer's work looks like under real conditions. A developer who builds clean, fast sites will welcome this. One who says "that score doesn't matter" or quickly steers you to a different site is answering the question with their reaction.

Take a peek behind one of their sites

You don't have to be technical to do this. On a portfolio page, right-click an empty spot and choose "View Page Source." You're not reading the code — you're eyeballing how tidy it is. A hand-built site looks clean and organized, with the behind-the-scenes labels that tell Google what the page is. A drag-and-drop page builder gives itself away: a wall of messy, repetitive gibberish, the same styling instructions copy-pasted over and over, and a long list of extra files all loading before the page can appear. If you're not sure what you're looking at, even glancing at it tells you something — clean code reads like a tidy filing cabinet, page-builder code reads like a stuffed junk drawer. A developer confident in their work won't mind you looking.

Ask why they made a specific choice

Pick something concrete: "Why did you choose this platform for my site instead of that one?" or "How do you keep my site working when my host updates its software?" You don't need to fully follow the answer. What you're watching for is whether they actually engage with the specifics or wave you off with generalities. A developer who can explain what they do and why in plain English has thought it through. One who says "I just use the standard approach" or changes the subject is telling you the decision was made on autopilot, not by thinking about your project.

Cross-check the ownership answer with a practical scenario

Ask directly: "Who owns the code at delivery?" Then, fifteen minutes later, ask: "If I want to switch to a different developer in two years, what do they need from me to get started?" The answers should match in substance. You hand the new developer the files you received at handoff, they set up a new host and point your domain name at it. If the second answer introduces conditions ("you'd want to stay on my hosting for continuity" or "the code is somewhat tied to my server setup") that the first answer didn't mention, the ownership picture is more complicated than the initial response suggested. Resolve the discrepancy before signing anything.

What they bring up before you ask

A developer who proactively walks you through how the contract hands ownership to you, describes how they'll deliver your site's files (and a copy of its data), names the specific behind-the-scenes labels they add to tell Google what your business is, and explains how they keep your security padlock active before you've asked has clearly had this conversation enough times that it's routine. A developer who only responds to these topics when you bring them up, and does so minimally without volunteering specifics, is either new enough that the conversation isn't routine yet or hoping you won't dig deeper. Both warrant more due diligence before you sign.

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 reasoning, not just the platform name. 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.