Questions to Ask Before You Hire Any Developer

Most hiring mistakes happen before the contract, not after. The right questions, asked before any money changes hands, eliminate the majority of bad fits early. What follows is the vetting framework I have refined over 18 years of building sites and watching other engagements go sideways.

The Short Answer Before We Get Into It

If you only do one thing differently after reading this, do it before you review a single proposal: write down what you need, decide what questions you will ask every candidate, and commit to asking all of them the same way. Consistency is what makes the comparison meaningful. Most business owners get excited about a portfolio or a smooth sales call and skip the hard questions. That is where the trouble starts. This checklist is the one I hand to clients who ask me how to evaluate other developers. It is not a guarantee of a perfect outcome, but it eliminates the obvious bad fits before a dollar changes hands.

Start With the Portfolio, and Actually Look at It

Portfolio review is the highest-signal screening step available to someone without a technical background. The key word is live. Ask for live URLs, not mockups, not Figma screenshots, not a PDF of what the site used to look like. Go to those URLs and actually use the sites.

On a desktop, open the browser developer tools (F12 in Chrome) and check the network tab for page weight. On your phone, load the site on a cellular connection, not Wi-Fi, and see whether it feels fast. A 1-second delay in page response can reduce conversions by roughly 7%, which matters enormously on rate-quote pages and application-start flows. If a developer's own portfolio sites are slow, that tells you something.

Look for relevant depth, not just visual range. A developer who has built forty e-commerce sites and one mortgage site has relevant depth in one industry only. If you are a loan officer or independent broker, you want someone who has solved your specific problems before: NMLS number placement, disclosure language near CTAs, rate tables that render correctly on mobile.

Ask the portfolio questions in sequence: Does any of this work look like my business? Can you show me the hidden performance issues a new developer should be able to identify on my current site? And before you commit to anyone, it is worth deciding whether you need a redesign or a full rebuild, because that answer shapes what kind of developer you need.

About 94% of first impressions of a business are design-related. A slow or broken portfolio site is not a minor flaw; it is a sample of the work you are about to pay for.

The Compliance Question Most Business Owners Forget to Ask

This section is written specifically for mortgage lenders, loan officers, and anyone in a compliance-sensitive financial services vertical. If that is not you, the principle still applies: does the developer understand the regulatory environment of your industry?

For mortgage and lending, the non-negotiables are:

NMLS license number display: Federal and state regulations require that NMLS IDs appear in specific places and specific formats. A developer unfamiliar with this will place them wherever looks clean.
RESPA-compliant disclosure language: Disclosure copy near CTAs is not boilerplate your compliance officer sends over after launch. It needs to be designed into the page flow from the start.
WCAG 2.1 accessibility standards: ADA Title III lawsuits targeting financial services and lending websites increased significantly between 2020 and 2023. Mortgage and real estate companies are among the most-cited industries in federal complaints. Ask explicitly whether WCAG AA compliance is included as standard.

A good answer to the compliance question sounds like this: the developer names these requirements without prompting and explains how they handle them structurally.

A bad answer sounds like this: "We can add whatever text your compliance officer sends us." That answer tells you they think compliance is a copy-and-paste problem, not a design and architecture problem.

Ignorance of these requirements is not a legal defense, and the cost of retrofitting a non-compliant site after launch routinely exceeds the cost of doing it right the first time.

Who Owns What When the Project Ends

This is the question that most business owners forget entirely until they want to switch developers and discover the site is effectively held hostage.

Only about 30% of small businesses have a formal written contract covering intellectual property ownership when hiring a freelance developer. The other 70% are operating on trust and assumptions, neither of which holds up in a dispute.

Technology lock-in takes several forms:

Proprietary CMS platforms: Some vendors build on systems that export no standard code. When you leave, you leave the site behind.
Bundled hosting: Hosting that is contractually tied to the development relationship, with no exit clause and no portable site files.
Single-developer builds: Sites architected so only the original developer can maintain or update them. This is sometimes an accident; sometimes it is intentional.

Five things your contract must address on ownership before you sign:

Who owns the source code and database upon project completion, and what form does delivery take?
Who controls the domain registration and DNS, and how is that access transferred?
Who holds the hosting account credentials, and what are the terms if you move to a different host?
Who owns the CMS license (if applicable), and is that license transferable?
Is there any code, plugin, or framework used in the build that carries a license restriction on resale or transfer?

If a developer hesitates on any of these, that hesitation is information.

Timeline, Revisions, and the Scope Creep Conversation

Scope creep is the primary driver of budget overruns in web development engagements. It is also almost entirely preventable if you handle it in the proposal stage.

A professional engagement has a written timeline with named milestones: discovery, wireframes, design review, development, UAT, launch. Not "six to eight weeks" with no structure underneath it.

Revision policy must be defined in writing:

How many rounds of revisions are included, and at which stages?
What is the difference between a revision (changing what was already agreed) and a change order (adding something new)?
Who decides when a request crosses that line?

The language to be most skeptical of in proposals is: "we will work with you until you are happy." That sounds generous. It is actually the absence of any defined scope, which means the developer can under-deliver indefinitely without being in breach, or alternatively you can request changes indefinitely and be surprised when the invoice arrives.

Before any of this becomes a contract conversation, write a complete project brief before you hire anyone. A developer who receives a detailed brief has no excuse for a vague proposal in return.

Post-Launch: The Questions Most People Never Think to Ask

Most proposals are written to win the project, not to describe what happens after launch. Post-launch support and maintenance are excluded from more initial proposals than they are included in, and the gap only becomes visible when something breaks.

Sites not maintained for Core Web Vitals, security patches, and algorithm updates degrade in search rankings within months. Google's ongoing core updates, including the May 2026 core update, reward sites that stay current and penalize those that stagnate. A site that ranks on launch day and slides off page one six months later is a common outcome when maintenance is not contractually defined.

Ask these questions before you sign:

What is your SLA for a site-down emergency? Two hours? Four hours? The next business day?
What is included in a maintenance retainer: security patches, Core Web Vitals monitoring, plugin updates, uptime monitoring?
Do you offer a retainer, and what does it cost?
Can you give me references from clients who have been on your books for more than one year, not just recently launched sites?

That last question separates developers who are good at launching from developers who are good at maintaining. They are not always the same person. For a detailed picture of what a responsible pre-launch process actually covers, I have written that out separately.

Where This Goes Wrong: Honest Tradeoffs to Know Upfront

A checklist is a filter, not a guarantee. A developer who answers every question on this list correctly is not automatically the right fit for your project. Budget, timeline, chemistry, and communication style all matter in ways that no checklist can capture.

Specialists cost more than generalists. A developer who knows NMLS display requirements, RESPA disclosure design, and WCAG 2.1 compliance from experience is going to charge a premium over someone who will Google those requirements after you sign. For a compliance-sensitive industry, that premium is usually worth it. But it is a real budget consideration, and pretending otherwise does not help you plan.

For context on what to expect at each budget tier, I have written out what a professional website project actually costs at each tier. Go read that before you evaluate any proposals so you know whether what you are being quoted is reasonable or not.

The goal of this framework is to eliminate the obvious bad fits and give you a more informed basis for the decision you will ultimately make anyway. The final call still involves judgment that cannot be systematized.

The Checklist, All in One Place

Here is everything consolidated into one scannable list. Copy it, print it, paste it into your notes app before your next developer call.

Portfolio

Can you share live URLs (not mockups) for sites you have built?
Do any of those sites serve clients in my industry or a compliance-sensitive niche?
How does the site perform on mobile on a cellular connection?

Compliance

Are you familiar with NMLS license number display requirements? (Good answer: yes, and here is how we handle them.)
How do you handle RESPA-compliant disclosure language near CTAs?
Is WCAG 2.1 AA compliance included as standard, or is it a separate line item?

Ownership

Who owns the source code and database at project completion?
Who controls the domain and DNS, and how is access transferred?
Is the CMS license transferable if I move to a different developer?
Is hosting bundled, and what are the exit terms?
Is any third-party code used that carries a transfer restriction?

Timeline and Scope

What are the named milestones in your project plan?
How many revision rounds are included, and how is a revision defined versus a change order?
How are change orders priced?

Post-Launch

What is your SLA for a site-down emergency?
What is included in your maintenance retainer?
Can you provide references from clients who have been with you for more than one year?

If you want to continue this conversation and talk through what you specifically need before hiring anyone, I am straightforward to reach.