Red Flags in Website Vendor Proposals to Watch For

A website proposal is the vendor's best work. It's the moment when they are most motivated to impress you, most careful with their language, and most attentive to your needs. If the proposal itself contains problems, the project will be worse. Every time.

I've been reading, writing, and evaluating website proposals for over 25 years. At FatLab, we manage roughly 200 WordPress websites, and a lot of our clients came to us after a failed engagement with another vendor.

I've also served as a technical consultant for organizations evaluating proposals from other agencies. They send us the documents because we'll be handling hosting, maintenance, and security long-term while another vendor handles the build. My primary concern when I evaluate a proposal is the maintainability of the final product. I've seen beautiful websites that are absolute spaghetti code underneath, and that disconnect between what the proposal promises and what actually gets built is where organizations get hurt.

That experience has given me a very specific perspective on what separates a trustworthy proposal from a dangerous one. Not the obviously bad proposals (the ones with typos and broken links), but the ones that look professional on the surface while concealing the problems that will surface six months into the project.

This isn't a generic checklist. These are patterns I've seen repeat across hundreds of projects, the warning signs I look for when a client hands me a stack of proposals and asks which vendor they should trust.

The Cost of Getting It Wrong

Before we get into specific red flags, understand the stakes. A 2024 GoodFirms survey found that 47 percent of organizations reported at least one failed web project in the preceding three years, with the most common causes being scope creep, poor communication, and unrealistic timelines. In our experience, the majority of website redesign projects exceed their original budgets, with overruns typically ranging from 25 to 50 percent above the initial quote.

But the real cost isn't the overrun on the first project. It's the second project.

We regularly see mid-market website projects that end up requiring a second vendor to fix or complete work started by the first. When you factor in the cost of the original engagement, the remediation work, and the time lost, organizations end up paying two to three times what they originally budgeted.

Organizations call us and say, "We just launched a new website, or we're about to launch, and we've decided we're not going to use the vendor who built it for hosting and support because we're not happy." That has to go back to the proposal and the contract. If the client were truly happy with the outcome, they wouldn't be looking for another vendor.

Nearly all of these failures are predictable at the proposal stage. Most failed web projects aren't technical failures. They're expectation-management failures that were baked into the proposal from day one. If you know what to look for, you can spot them before you sign anything.

Red Flag: Undefined Scope

This is the one I see most often, and it's the most consequential. A proposal that says "we will build you a website for X dollars" without defining what the website actually does has not defined the project. If we haven't defined the project, why would we know how much it costs?

A cheap proposal is one that's designed to win the project, give a low number without defining what you're going to build. The theory is: win the client, then deal with it later.

I've talked about this in the context of writing a strong RFP, and the same principle applies when evaluating the responses. A proposal without a defined scope is a blank check. Everything not explicitly listed becomes a potential change order, and the vendor knows this even if you don't.

Here's what a vague scope actually looks like in a proposal:

• "Development" listed as a single line item with no breakdown of frontend, backend, or integration work
• "Design" without specifying the number of design concepts, revision rounds, or page templates included
• No mention of content migration, redirects, or training
• Features described in marketing language rather than functional terms: "dynamic user experience" instead of "filterable directory with search and member login."

In our experience, projects with vaguely scoped proposals generate far more change orders and higher costs than well-scoped projects. The scope gap is where vendors recover margin on low bids.

The "Assumed Inclusions" Problem

One of the most common sources of disputes in web projects is the gap between what clients assume is included and what vendors consider extra.

Clients assume mobile-responsive design is standard. The vendor calls it a "mobile optimization package." Clients assume the site will show up in Google. The vendor calls it "SEO optimization." Clients assume they'll be able to edit the site themselves. The vendor calls it "CMS training sessions." Security, fast loading, cross-browser compatibility, and working contact forms: clients assume these are part of building a website. Vendors often treat each one as a separate line item. If a proposal doesn't explicitly list it, it's not included.

Here's a practical example. A bad capabilities section says: "We are a membership organization and we want our members to be able to sign in and access member-only material." A strong one says, "We are a membership organization with three levels of members. We'd like members to log in and access directories, PDFs, and gated content based on their membership level. Additionally, we'd like members to pay their dues, track payments, and download previous year invoices." The difference between those two descriptions is the difference between a well-scoped project and an expensive series of change orders.

What you should see instead: a proposal that lists every feature, every page template, every integration point as a discrete deliverable. I tell clients that if it doesn't have a bullet, it's not considered in scope. The more bullet points, the better the project will go and the happier everyone will feel at the end.

Red Flag: Pricing That Doesn't Add Up

There's no regulatory body in our industry. Pricing can be all over the place, and that makes it easy for vendors to take advantage of clients who don't understand what they're asking for.

I recently evaluated a proposal for a nonprofit in Washington, DC. It was a website I would have built for tens of thousands of dollars, and the vendor had bid $150,000. That's a case of someone taking advantage of a client who didn't understand the technical implementation of what they were asking for. On the other end, I regularly see proposals that are clearly designed to win on price alone, with numbers so low they can only mean the vendor is cutting corners or plans to make it up in change orders.

The reverse is equally problematic. When an RFP claims a low budget but then describes needing a sophisticated website with extensive functionality, that's a mismatch that signals trouble. It's like hiring a house painter and then asking them to remodel your kitchen. They might try, but the skill set doesn't match the ask, and no one will be happy with the outcome.

If it's too good to be true, it probably is. You probably don't want to go with your lowest bidder, and you probably don't want to go with your highest bidder either.

What Suspiciously Low Pricing Usually Means

When a bid comes in at a fraction of the market rate, it typically means one of several things:

• The work will be done offshore without disclosure, and the communication and timezone challenges will never be budgeted for.
• The vendor is using a $50 to $150 commercial template that they'll present as custom design work.
• The scope is deliberately vague so the vendor can recover margin through change orders.
• The vendor is inexperienced and genuinely doesn't know how long things take, which means they'll either deliver poor quality or realize mid-project that they can't complete the work profitably.

In our experience, the total cost of ownership for extremely low-cost offshore development regularly ends up two to three times the initial quote when you factor in rework, communication overhead, and remediation.

Payment Structure Red Flags

Beyond the total price, pay attention to how the vendor wants to be paid. Legitimate vendors typically require 25 to 50 percent upfront, with the remainder tied to milestones: design approval, development completion, and launch.

A vendor willing to start with no deposit either has no pipeline and is desperate for work, or plans to hold deliverables hostage later. A vendor demanding 100 percent upfront puts all the risk on you with no leverage if the work is substandard. And hourly-only pricing with no cap on a defined-scope project means the vendor has no incentive to be efficient with your budget.

The other end of the pricing spectrum matters too. Your website is a 24/7 window into your organization. Especially for nonprofits and associations with membership portals, dues collection, or event RSVPs, this is not the place to save money. A well-built website will serve you for years. The saying "you get what you pay for" is very true in this industry.

How to Evaluate Pricing Without Being Technical

As a non-technical person, you need to see whether the vendor has allocated hours to the budget or allocated scope to the price. If neither, get those things. Make sure the scope is well-defined or that hours are provided, so you have a way to measure how they arrived at their price. This is also where getting multiple bids helps, because you'll be able to see the average.

And if you really like the lowest bidder, it's worth going back to them and having a conversation. Ask why their bid came in where it did. You'll probably find, through that conversation, that things weren't included, the scope wasn't defined, and so on. Get those things nailed down before you sign an agreement.

For a complete framework on comparing proposals side by side, including how to normalize different pricing structures, see our guide to evaluating website proposals.

Red Flag: No Discovery Phase

The single most predictive red flag for project failure is the absence of a discovery or strategy phase. Discovery is when the vendor learns about your organization, audience, goals, and constraints. It typically involves stakeholder interviews, a current site audit, competitive analysis, content inventory, and technical requirements gathering.

A vendor who skips discovery is guessing at the solution. And guessing is how you end up with a website that looks nice but doesn't do what your organization actually needs. Research from Forrester found that projects with formal discovery phases were 2.7 times more likely to be delivered on budget and 3.1 times more likely to meet stakeholder satisfaction goals.

When a client is unhappy with the end product, it's often not the quality of what the developer or designer created. It's that they didn't get what they wanted because they didn't know what they wanted.

That's why in our discovery process, I always start with the dream. I tell everyone in the room: this is your dream. What do you want this website to do? Then we figure out what's realistic within the budget and timeline.

A proposal that jumps straight from "you contacted us" to "we'll start building" has skipped the most important step. There's a reason discovery exists: it protects both the client and the vendor from building the wrong thing.

Red Flag: Deferred Critical Decisions

Some proposals acknowledge complexity but push the hard decisions into the future. Watch for proposals that defer critical decisions to later in the project:

• "CMS to be determined" affects everything downstream. If the CMS isn't decided, the estimate is meaningless.
• "Third-party integrations TBD" is a major red flag because integration work is often 30 to 50 percent of development time. Deferring this means deferring the real budget.
• "Content strategy in Phase 2" ignores the reality that content drives design. Designing without a content strategy produces a brochure that doesn't serve the organization's goals.
• "SEO will be addressed post-launch" tells you the vendor doesn't understand modern web development. Retrofitting SEO is three to five times more expensive than building it in from the start.

Every deferred decision is a scope gap, and scope gaps become change orders. When a client adds something mid-project and the vendor pushes back, the client becomes unhappy. They think the vendor is nickel-and-diming them. And that's the beginning of the end of a productive working relationship.

Red Flag: Unrealistic Timelines

A custom 20-page website in four to six weeks is either template-based development being sold as custom work, or a timeline that will blow past the deadline. Quality web development takes time, and a realistic timeline for a custom WordPress site with 15 to 30 pages runs 16 to 28 weeks when you account for discovery, design, development, testing, and content loading.

Watch for these timeline warning signs:

• No discovery or strategy phase in the timeline. If the timeline starts with design, the vendor is guessing.
• Testing compressed into "a few days" or absent entirely. Testing is a phase, not an afterthought.
• No content loading or migration time. This is a classic source of delays that the vendor will blame on you.
• Development starting before design approval. This means the vendor is building before you've agreed on what they're building.

Fast timelines are appealing when you're eager to launch, but speed and quality rarely coexist in web development. A proposal that promises both is usually delivering neither.

Red Flag: Template Work Sold as Custom

This is one I catch when reviewing clients' portfolio sites. I visit those portfolio sites and, assuming it's WordPress, I look at the markup. Are they building custom themes or using bloated commercial themes? How many plugins does it look like are installed? Is the CSS clean, or did a page builder generate it?

If I find a portfolio full of commercial themes and heavy plugin usage, that's a red flag.

Template-based development is a legitimate approach that reduces cost. There's nothing wrong with a $2,000 site built on a commercial theme. The red flag is when it's sold as custom work at custom prices. A $25,000 site built on a $59 template and presented as "custom designed" is a different story entirely.

Indicators that a vendor is selling template work as custom:

• A very fast design phase, one to two weeks for a "custom" design
• The design concept looks production-ready immediately, because it already is
• Limited flexibility during the design phase when you request structural changes
• The vendor can't modify layout elements without a high additional cost
• Every site in their portfolio follows the same basic structure with different colors and images

A vendor who provides real custom development services can meet each challenge of your project with creativity and freedom. A point-and-click developer, someone who installs a commercial theme, changes some colors, and loads up plugins, simply can't offer that. The problem is that both types of vendors claim to be "developers."

This is a technical project, and you need technically savvy people working for you. Ask whether the development team writes their own code, understands the server stack, and can build custom solutions, or whether they're limited by what a commercial theme or plugin marketplace can provide. Ask whether they'll build a custom theme or adapt your design to a pre-built theme. These questions tell you more about what you'll actually get than any portfolio screenshot.

For guidance on telling the difference, see our article on how to choose a web developer.

Red Flag: Ownership and Lock-In Traps

This is the most consequential category, and the one most clients miss because it lives in the contract rather than the proposal narrative. But a good proposal addresses it proactively. A bad one stays silent and lets the contract do the work.

IP and Source File Ownership

Some contracts grant the client a license to use the website but retain IP ownership with the vendor. This means the client can't take their site to another developer, modify the code, or, in some cases, even move hosts.

We've seen this firsthand: a surprising number of small businesses discover they don't own their website or domain only when they try to change vendors. The cost to recover or rebuild typically runs $12,000 to $18,000.

What you should own after a website project:

• All custom code, themes, and plugins built specifically for you
• All design source files (Figma, Sketch, PSD), not just flattened exports
• All content you provided and all content created for you during the project
• Your domain name registration
• Administrative access to your hosting account
• All login credentials for every service connected to your site

If the proposal doesn't address ownership, ask about it. If the answer is anything other than "you own everything we build for you," that's a red flag.

Hosting and Platform Lock-In

Some vendors build your site on their proprietary platform or bundle it with hosting that only works with their infrastructure. If you leave the vendor, you lose the site. Others register your domain in their own account, build on a proprietary CMS, or deploy from private repositories you can't access.

This lock-in isn't always malicious. Some vendors genuinely believe their platform is the best option. But the effect is the same: you're dependent on that vendor indefinitely, and leaving means starting over. A proposal that requires you to use the vendor's hosting, use a proprietary CMS, or does not indicate that you'll have direct access to your own site's codebase should be questioned.

Maintenance Lock-In

Required maintenance contracts with cancellation penalties, automatic renewal clauses with narrow cancellation windows, and pricing that escalates annually without matching service improvements are all signs that the vendor's business model depends on keeping you locked in rather than keeping you satisfied.

There's a meaningful difference between a vendor who earns your ongoing business by providing genuine value and one who structures their contracts so that leaving is painfully expensive or technically difficult.

Red Flag: Portfolio and Reference Warning Signs

When I evaluate proposals on behalf of clients, I don't just read the document. I visit the portfolio sites. Most clients aren't doing this, but I look at the markup and figure out what technologies they're using. Even without technical skills, you can learn a lot from a vendor's portfolio.

Check whether the portfolio sites are actually functional. Dead links, SSL errors, slow loading, and mobile issues in a vendor's own showcase work tell you everything about their quality standards. Look for variety in the portfolio. If all their sites look identical, the same layout with different colors and images, you're looking at template-based work regardless of what the proposal claims.

Pay attention to references as well. A vendor who can provide references only from the last six months has no long-term client relationships, suggesting clients leave after the initial project. A healthy agency retains at least 60 to 70 percent of clients for ongoing work after launch. If an agency's entire business model is one-and-done projects, their incentive to build maintainable, well-documented sites is low.

And if a vendor claims they've never had a difficult project, that's not credibility. Every vendor has had a difficult project. One who claims otherwise isn't being honest with you.

Red Flag: Communication Problems During Sales

The sales process is the vendor's best behavior. If they're slow to respond, disorganized, or evasive during the phase when they're most motivated to impress you, expect those problems to get much worse during the project.

Watch for these communication signals:

• Slow response times. If they take three to five business days to respond to a proposal question, expect one to two weeks during development.
• No dedicated point of contact. "The team" responds to emails rather than a named individual.
• Can't articulate their process. If they can't clearly explain how a project flows from kickoff to launch, they don't have a repeatable process.
• Evasive about team composition. Unwillingness to disclose who will actually work on your project often means it will be subcontracted to people you'll never meet.
• The proposal is generic. If the proposal could apply to any business in any industry with no mention of your specific challenges, audience, or goals, the vendor didn't invest time in understanding your organization. That pattern will continue through the project.

Missing Process Details

A good proposal outlines the working relationship, not just the deliverables. How many rounds of revisions are included? What format should feedback take? When does the client formally sign off before the next phase begins? What happens when there's a disagreement? How frequently will the vendor provide status updates?

If the proposal is silent on all of these, the vendor either doesn't have a process or doesn't think it's worth explaining. Neither answer is reassuring.

Red Flag: No Post-Launch Plan

A proposal that ends at launch tells you the vendor views the launch as the finish line. It's not. Launch is the starting line. What happens after matters more than most organizations realize, and it needs to be part of the conversation before you sign anything.

Post-launch basics that should be addressed somewhere in the proposal process:

• CMS and plugin updates. WordPress releases security patches roughly monthly, and plugins update even more frequently. Sites that go six or more months without updates accumulate critical security vulnerabilities.
• Backup management. Automated backups with off-site storage and periodic restore testing.
• Security monitoring. Uptime monitoring, malware scanning, vulnerability alerts.
• Bug fix warranty. Industry standard is 30 to 90 days for bugs related to the original scope. If this isn't mentioned, you have no recourse when something breaks after launch.
• Training. How will your team learn to use the site? "One 30-minute session" for a complex site with custom post types, forms, and membership management isn't sufficient.

There's a recognizable pattern in the industry: responsive and enthusiastic during sales, engaged during the project (though often slow), rush the launch to close the invoice, then disappear after final payment. Support requests go unanswered or get charged at premium rates.

This pattern is detectable at the proposal stage. If there's no discussion of the post-launch relationship, you know what to expect.

Red Flag: Missing Essential Sections

A complete website proposal should address certain topics. Missing sections aren't oversights. They're exclusions. If the proposal doesn't mention it, it's not included.

Content migration. Who moves the existing content? In what format? How many pages? Is there a content audit? Content migration is one of the most labor-intensive parts of a website project, and if it's not scoped, the cost will land on you, either in time or in change orders.

Redirects. If URLs are changing during a redesign, who maps and implements 301 redirects? Missing this destroys years of accumulated SEO value. For more on what a redesign RFP should cover, see our guide to website redesign RFPs.

Accessibility. WCAG 2.1 AA compliance is the minimum legal standard for many organizations, particularly nonprofits and government-adjacent entities. If accessibility isn't built in, retrofitting it later costs a lot more.

Performance targets. What are the load time goals? What about Core Web Vitals? Without targets, you have no way to measure whether the site performs acceptably.

Analytics. GA4 setup, conversion tracking, event configuration. If the vendor isn't setting up analytics, you won't be able to measure whether the new site is performing better than the old one.

Hosting guidance. Some vendors deliver a completed site with no guidance on hosting requirements. The client is left to figure out hosting on their own, which often leads them to choose inadequate shared hosting that can't run the site properly.

Nonprofit and Association Considerations

If you're a nonprofit or association evaluating proposals, you face additional dynamics that most red flag articles don't address.

Board-approved budgets and formal procurement processes make switching vendors mid-project politically difficult. You can't just fire a vendor and start over. You may need board approval, a new procurement cycle, and months of delay. This is why getting the vendor selection right the first time matters even more for mission-driven organizations.

Grant-funded projects with fixed budgets and reporting requirements add another layer. A vendor who triggers significant change orders on a grant-funded project creates a compliance problem, not just a budget problem.

Committee-based decision-making can be exploited by vendors who present to non-technical stakeholders. A polished presentation to a board or selection committee can mask fundamental problems in the proposal that a technical reviewer would catch immediately.

A Note on the Competitive Bid Process

I'll say this directly because it's something vendors rarely talk about publicly: the formal competitive bid process that many nonprofits and associations are required to follow is frequently not competitive at all.

I've been on both sides of this. I've submitted proposals where I found out later that I was just the obligatory competing bid because the board requires it. The organization already knew exactly who they were going to hire. And I've seen what happens next. The organization collects all the bids, gathers the good ideas, scope suggestions, and pricing, and hands it all over to their vendor of choice, who then puts together a winning bid using everyone else's work. I consider that unethical business, but it happens more often than organizations want to admit.

If you're running a genuine competitive process, be transparent about it. Let vendors know the process is real, that you're evaluating proposals fairly, and that there's no predetermined winner. Quality vendors will not invest 25 or more hours on a proposal if they sense the outcome is already decided. If you want the best vendors to take your RFP seriously, they need to believe the process is honest.

For procurement considerations specific to nonprofits and associations, including how to structure a fair competitive bid process, see our nonprofit website RFP guide.

What a Good Proposal Actually Looks Like

After spending this entire article on warning signs, here's what you should expect from a thorough, trustworthy vendor.

A good proposal defines the project. Every deliverable is listed. Every feature is described in functional terms. The scope is specific enough that both parties know exactly what's being built and what isn't.

A good proposal explains the process. Discovery, design, development, testing, launch, and post-launch support are all described with realistic timelines and clear milestones. You know when you'll be involved, what decisions you'll need to make, and how feedback will be handled.

A good proposal is transparent about pricing. Line items correspond to deliverables. You can see how the vendor arrived at their number. Hours or scope are tied to the price, so you can evaluate whether it's reasonable.

A good proposal addresses the future. It tells you who owns the work, how the site will be maintained, what happens if the relationship ends, and what the first year after launch looks like.

A good proposal is specific to your organization. It references your goals, your audience, and your challenges. It demonstrates that the vendor invested time in understanding your situation before they proposed a solution.

A good proposal considers long-term maintainability. It addresses not just what will be built, but how it will be maintained. Is the vendor's answer to every problem "install another plugin," or do they think about the system as a whole? A proposal that weighs its technology recommendations for low overhead and technical simplicity is thinking beyond launch day.

A good proposal acknowledges what it doesn't know. The best vendors will tell you what they need to learn during discovery before they can finalize the scope. Honesty is worth more than a vendor who claims to have all the answers before the project starts.

If you're starting the RFP process and want to make sure you're giving vendors the information they need to produce strong proposals, our website RFP guide covers the process from the beginning. We also have a website RFP template and real examples of effective vs. ineffective RFP language to help you get started.

Frequently Asked Questions

How many proposals should I get for a website project?

Three to five proposals is the sweet spot for most organizations. Fewer than three doesn't give you enough data points to compare pricing and approach, while more than five creates evaluation fatigue and makes it harder to give each vendor fair consideration. The goal isn't to find the cheapest option but to see how different vendors interpret your requirements and where their approaches diverge.

What is a normal deposit for a website project?

Most legitimate web development vendors require 25 to 50 percent upfront, with the remainder tied to project milestones like design approval, development completion, and launch. Be cautious of vendors who ask for nothing up front, as that can signal desperation, and equally cautious of vendors who demand full payment before work begins, as that removes all your leverage if the work falls short.

How long should a custom website take to build?

A realistic timeline for a custom WordPress website with 15 to 30 pages is 16 to 28 weeks, accounting for discovery, design, development, content loading, testing, and launch. Proposals promising a custom site in four to six weeks are almost certainly using templates or planning to cut corners on discovery and testing. Faster timelines are possible for simpler sites, but complexity, integrations, and content migration all extend the schedule.

Should I own the code for my website?

Yes. After a website project, you should own all custom code, themes, and plugins built specifically for you, along with design source files, content, domain registration, and all login credentials. If a vendor retains ownership of the code or builds on a proprietary platform you cannot take with you, you are locked into that vendor indefinitely. Ask about ownership before you sign anything, and get it in writing.

What questions should I ask a web developer before hiring them?

Ask whether the development team writes custom code or relies on commercial themes and plugins. Ask who will actually work on your project and whether any work will be subcontracted. Ask what CMS they recommend and why, what their discovery process looks like, how they handle change requests, and what post-launch support is included. The clarity and specificity of their answers will tell you more than their portfolio or sales pitch.

How can I tell if a web design proposal is too cheap?

Compare the bid against the scope of work being described. If a vendor promises a complex, custom-built website with integrations, membership features, and a custom design for a fraction of what other vendors quoted, something is missing. Common explanations include undisclosed offshore labor, template-based work presented as custom, a deliberately vague scope that will generate change orders, or a vendor who genuinely underestimates the effort involved. Ask the vendor directly how they arrived at their number and what assumptions they made about scope.

Protect Your Organization

The proposal stage is where nearly every web project failure begins. A bad proposal doesn't just reflect poor sales practices. It predicts poor project execution.

Every red flag described in this article is a pattern I've seen play out repeatedly across hundreds of projects over 25 years. The good news is that these patterns are identifiable. You don't need to be technical to spot them. You just need to know what to look for and be willing to ask hard questions before you sign.

FatLab Web Support manages roughly 200 WordPress websites for nonprofits, associations, and organizations nationwide. If you're evaluating proposals and want a technical perspective before you commit, get in touch.