6 Red Flags in a Web Development Proposal (and the exact questions to expose them)
Most web and mobile projects don’t fail because of “bad code.” They fail because expectations were never made explicit: what’s included, what’s not, who owns what, and what “launch-ready” actually means.
At Jensen Technologies, we’ve been building websites and apps for many years. We’ve seen proposals that look polished on the surface but hide risk in vague wording. Below are six common red flags-and the simple questions that quickly separate a solid delivery team from a risky bet.
1) Ambiguous deliverables
Red flag: The proposal promises something like “a modern website” or “a complete app” without a detailed breakdown.
Why it matters: If deliverables aren’t listed, you can’t compare vendors, manage scope, or know what you’re paying for. Ambiguity is where budget overruns live.
Ask: “Can you list every deliverable (pages, templates, components, integrations) and define what ‘done’ means for each?”
What good looks like: A clear inventory (e.g., number of page templates, reusable components, CMS content types, specific third-party integrations) plus acceptance criteria.
2) Hosting, ownership, and access are unclear
Red flag: You can’t clearly tell who owns the domain, hosting account, source code, design files, analytics, or app store listings.
Why it matters: Ownership and access determine whether you can switch vendors, bring work in-house, or simply keep operating if a relationship changes.
Ask: “On day one and day 100, which accounts are in our company’s name, and what happens at handover?”
What good looks like: Your business owns the critical accounts, documented access is provided, and handover is treated as a normal (and testable) part of delivery.
3) Scope creep is inevitable-but the proposal doesn’t manage it
Red flag: Lots of “out of scope” clauses, but no practical method for evaluating and approving changes.
Why it matters: Requirements evolve. The question isn’t whether you’ll change your mind-it’s whether the process stays fair, predictable, and fast.
Ask: “How do you handle changes-what’s the approval flow, typical cost range, and who signs off?”
What good looks like: A lightweight change-control approach: written estimate, impact on timeline, clear approval milestone, and a shared backlog of decisions.
4) Testing, performance, and accessibility are missing or hand-wavy
Red flag: QA is a single bullet point, accessibility isn’t mentioned, and performance is assumed to “just work.”
Why it matters: Bugs and slow experiences cost more after launch. Accessibility and basic quality standards are easier (and cheaper) when planned early.
Ask: “What is your test plan (devices/browsers), performance budget, and accessibility target (e.g., WCAG 2.1 AA)?”
What good looks like: A defined QA process, minimum supported browsers/devices, performance goals, and an accessibility posture that matches your audience and risk profile.
5) Timelines without milestones (or without your responsibilities)
Red flag: A single delivery date with no phases, no checkpoints, and no list of what the client must provide.
Why it matters: Most delays are dependency delays: content, approvals, brand assets, legal text, app store credentials, stakeholder sign-off.
Ask: “What are the milestones, what do you need from us by when, and what happens if inputs are late?”
What good looks like: A milestone plan (discovery, wireframes, design, build, QA, launch) and a mutual dependency list that protects both sides.
6) Post-launch support and SLAs are vague
Red flag: “Support available” without response times, monitoring, security patching expectations, or a release cadence.
Why it matters: Launch is the start of real-world usage: traffic spikes, edge cases, browser updates, plugin vulnerabilities, OS changes, and user feedback.
Ask: “What are your support tiers, response times, monitoring tools, and patch/release cadence?”
What good looks like: Clear support options (including emergency pathways), monitoring/alerting, and an agreed process for updates and improvements.
A practical way to use this checklist
- Use the questions above in a single email to every vendor you’re considering.
- Compare the clarity of the answers-not just the price.
- Watch for defensiveness or vague replies. Strong teams welcome specificity.
If you’d like to discuss any of these points-or you want a second opinion on a proposal you’ve received-get in touch with Jensen Technologies. We’re happy to help you pressure-test the scope and set your project up for a smooth build and launch.