How to Brief a Web Developer So Your Project Goes Right

To brief a web developer properly, write down eight things before you make the first call: platform choice, integrations, content ownership, hosting expectations, performance benchmarks, compliance requirements, analytics setup, and launch timeline. A developer who has those answers can quote your project accurately. One who does not will quote a project they have not actually scoped.

What a Developer Actually Needs Before They Can Quote You

A quote without a scope is a guess. Before any number a developer gives you means anything, they need five things from you: the platform or CMS you expect to use, a list of third-party integrations, clarity on who owns the content, your hosting and maintenance expectations, and any compliance requirements specific to your industry.

Leave any one of those open and you have handed the developer permission to make assumptions. Assumptions become change orders. That is how an $8,000 website becomes a $15,000 website, not because anyone was dishonest, but because the scope was never actually defined.

Platform matters because the labor cost of building on WordPress is different from Webflow, which is different from a custom stack. If you have not discussed this, the developer is quoting a project they have not yet scoped. Integrations matter because connecting a rate engine or loan origination system to a contact form is not a minor addition. Content ownership matters because if you are not delivering copy and images on a schedule, the project will stall at 85 percent complete for months. Hosting expectations matter because managed hosting is a recurring cost with real implications for who handles security updates. Compliance matters because in regulated industries, a polished site with missing disclosures is worse than no site at all.

It is also worth discussing the platform decision carefully with your developer before committing. Some platforms that look attractive for their visual editors carry real architectural debt, which is why I have written separately about why page builders can create problems down the road. That conversation belongs in the brief stage, not after the contract is signed.

The Brief Checklist: Eight Things to Nail Down Before the First Call

This checklist exists to protect you, not to make your life harder. A developer who sees these eight items answered will quote your project accurately. A developer who cannot answer them without asking you will at least ask the right questions.

CMS or platform choice. If this is left open, you may end up on a platform that your team cannot edit without calling a developer every time. Discuss this explicitly. For some business sites, it is also worth deciding early whether a static site is the right architecture for your needs, since that choice changes both the build cost and the ongoing maintenance story.
Third-party integrations. List every system the site needs to connect to: CRM, mortgage calculator, rate engine, live chat, LOS, email marketing platform. If you forget one, expect a change order.
Content ownership and deadlines. Specify who writes each page, who provides images, and when they will be delivered. If this is left vague, content delays will stall your launch.
Hosting and maintenance expectations. Decide upfront whether the developer hosts and maintains the site, whether you handle it internally, or whether you are moving to a managed platform. Leaving this until after launch creates gaps in responsibility.
Performance benchmarks. Specify Core Web Vitals targets: LCP under 2.5 seconds, CLS under 0.1. Without a written benchmark, you will get a site that looks fine and performs poorly.
Compliance requirements. For any regulated industry, list every disclosure, license display, or accessibility standard required. If it is not in the brief, it will not be in the original quote.
Analytics and conversion tracking setup. Specify whether you need Google Analytics 4, Google Tag Manager, call tracking, or form submission events. Developers do not automatically wire these up unless you ask.
Launch timeline. Give a target date with any hard constraints. If you have a marketing campaign, a licensing deadline, or a conference date, write it down so the developer can flag whether the timeline is realistic.

Mortgage and Lending Sites Have Extra Requirements. Write Them Down.

Mortgage websites carry regulatory overhead that generic web briefs almost never capture. If your developer has not built in this space before, they will deliver a visually polished site that creates legal exposure from day one.

Here is what belongs in your brief as explicit written requirements, not assumptions:

NMLS ID display. All licensed mortgage companies are required to display their unique NMLS ID on their website as a condition of licensure in participating states. It needs to be visible on every page, typically in the footer.
NMLS Consumer Access link. A direct link to the NMLS Consumer Access portal is a licensing requirement. It is not optional design.
Equal Housing Lender logo. Placement and sizing have specific requirements. A developer unfamiliar with this will treat it as a generic footer icon.
State-specific licensing pages. If you are licensed in multiple states, each state may require its own disclosure page with specific language. This is a content and architecture requirement, not just copy.
RESPA and TILA compliance copy. Rate quotes, fee disclosures, and APR language are governed by federal law. The developer needs to know this copy exists and where it lives on the site.
Rate disclaimer language. Any page displaying rates needs properly formatted disclaimers. Where they appear, how they are formatted, and how often they update are all specification-worthy items.

On top of all of this, WCAG 2.1 AA accessibility is a legal obligation for financial services firms, not a nice-to-have. The DOJ issued formal guidance in March 2022 confirming that Title III of the ADA applies to websites of businesses open to the public, including lenders. WCAG AA compliance should be a written requirement, not an assumption in your brief, because many developers do not include an accessibility audit in a standard quote.

Performance is equally non-negotiable. With 45 percent of financial services web traffic coming from mobile devices, page speed directly affects whether borrowers find you in local search. The performance benchmarks worth including in your spec are LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. A developer who has built mortgage sites will already know this. One who has not will need you to specify it.

Questions to Ask on the First Discovery Call

The first call reveals more about a developer than their portfolio does. Here are five questions worth asking, along with what a good answer looks like versus a red flag.

1. Have you built sites in a regulated industry before? What compliance requirements did you handle?
Good answer: They name specific requirements, describe how they handled disclosure placement, and mention working with compliance reviewers. Red flag: They say the site looked great and the client was happy, with no mention of what made it legally compliant.

2. How do you handle accessibility? Is WCAG 2.1 AA part of your standard build or is it a separate line item?
Good answer: They describe their testing process, name specific tools (axe, Lighthouse, manual keyboard testing), and explain whether it is included by default. Red flag: They say they follow best practices or that their themes are accessible, without describing any actual testing.

3. What does your discovery process look like before you write a scope document?
This question reveals whether they have a process or whether they are making things up as they go.

4. How do you handle content that arrives late from the client side?
A developer who has done this before will have a clear answer involving contract language and a defined holding process.

5. What does success look like 90 days after launch, in your view?
This separates developers who think in deliverables from developers who think in outcomes.

Red Flags Go Both Ways

I want to be honest here because most articles like this one only list developer red flags. Both sides of the table have them.

Developer red flags: No discovery phase before quoting. No questions about your compliance requirements on the first call. A quote delivered in under 24 hours without a scope document attached to it. Price is the only differentiator they can articulate. They have never heard of NMLS Consumer Access.

Client red flags developers watch for: No budget range given at all, which wastes everyone's time and signals that the client has not done any internal alignment. Saying "I just need something simple" about a regulated site with a CRM integration, rate engine, and five state licensing pages. Vague approval chains where it is unclear who has final sign-off. "Can you just look at this other site and do that" without any brief, any content, or any understanding of what that other site actually required to build.

I have been on both sides of bad project kickoffs. The brief process exists precisely to surface these mismatches before money changes hands. If a client cannot answer the eight checklist items, the project is not ready to start. If a developer cannot ask good questions about a regulated industry, they are not ready to quote it.

Fixed Price vs. Hourly: Which One Fits a Mortgage Site Build

For a mortgage site build with compliance variables, I recommend a phased fixed-price approach over pure hourly. Here is why.

Pure hourly billing puts the financial risk entirely on the business owner, who typically cannot audit hours on a technical project. You are trusting that the work took as long as billed, without the expertise to verify it.

Fixed-scope projects work well when the scope is actually fixed. For a mortgage site, the scope rarely is, because compliance requirements vary by state, content arrives in waves, and integration complexity often surfaces mid-build.

The decision rule: if you have completed the eight-item checklist and your compliance requirements are documented, a fixed-price phased contract works. Phase one covers design and core development. Phase two covers integrations and compliance build-out. Phase three covers content, testing, and launch. Each phase has a defined deliverable and a defined cost. If scope changes, it triggers a change order within the next phase, not a runaway invoice.

What a Realistic Timeline Looks Like and What to Hold the Developer To

For a mortgage website build or redesign, a realistic phase-by-phase timeline looks like this:

Discovery and brief finalization: one to two weeks
Design (wireframes through approved mockups): two to three weeks
Development (core build, CMS setup, integrations): three to five weeks
Compliance build-out and accessibility audit: one to two weeks
Content population and QA: two to three weeks (this phase almost always slips)
Launch and post-launch monitoring: one week

Total: ten to sixteen weeks for a proper build. Any developer quoting six weeks for a full mortgage site with state licensing pages and LOS integration is either underselling the scope or planning to cut corners.

Content delivery is the most common reason a project sits at 80 percent complete for three months. That is not a developer problem. The business owner is responsible for their part of the timeline, and a good contract will make that explicit with defined content deadlines and a holding fee if they are missed.

Take the checklist above, fill it out before your first call, and you will have a materially better project than most of the ones I have seen go sideways.