Ten red flags in web/app/AI development proposals (and what good looks like)
When you’re hiring a team to build a website, mobile app, or AI feature, proposals can look reassuringly similar: a timeline, a price, and a list of “included” items. But small gaps in a proposal often turn into the biggest sources of delay, budget creep, and long-term maintenance pain.
Jensen Technologies has been delivering web projects for many years, and we’ve seen the same patterns repeat-especially as AI gets added to otherwise “normal” web and app builds. Below are ten practical red flags to look for, plus what a solid proposal typically includes.
1) Vague scope (“Build an app like X”)
Red flag: The proposal describes outcomes in broad terms but doesn’t define what’s actually being built.
What good looks like: User journeys/user stories, specific screens and flows, what’s in scope vs out of scope, and a written assumptions list. Also: a clear change-control process (how new requests get estimated and approved).
2) One big number with no breakdown
Red flag: A single fixed price that lumps everything together-design, development, testing, launch-without showing effort distribution.
What good looks like: Itemized phases and deliverables (discovery, UX/UI, implementation, QA, launch), plus what you receive at each milestone. Even if pricing is fixed, the breakdown reveals whether the plan is realistic.
3) Ambiguous ownership of code, designs, and accounts
Red flag: You’re not sure who owns the source code, Figma files, domains, analytics, and cloud accounts-or you’re told they’ll “manage it for you” without details.
What good looks like: Written confirmation that you own your IP and will have admin access to critical accounts. A professional team can still manage infrastructure day to day, but ownership and access should be non-negotiable.
4) No explicit security approach (especially for AI)
Red flag: “Security” is a single bullet point, or missing entirely. AI amplifies risk because it introduces new data flows, vendors, and sometimes prompt injection vectors.
What good looks like: A baseline security plan: authentication/authorization model, least-privilege access, secret management, dependency patching, audit logging where appropriate, and OWASP-aligned practices. For AI: data retention policy, PII handling, vendor/model risk notes, and guardrails for unsafe or off-topic outputs.
5) Testing is deferred (“We’ll test at the end”)
Red flag: QA appears as a small line item at the end, with no test criteria. This often leads to difficult launches and costly rework.
What good looks like: A test strategy from the start: acceptance criteria per feature, automated tests where they pay off (unit/integration), and a defined device/browser matrix for manual testing. The proposal should budget time for bug fixing-not just bug finding.
6) Aggressive timeline without tradeoffs
Red flag: A fast delivery promise with no explanation of what’s being simplified, what’s excluded, or what depends on you providing content/feedback quickly.
What good looks like: A timeline that matches team size and complexity, with explicit dependencies (e.g., “copy by date X”, “legal review by date Y”). If there’s a hard deadline, a good proposal explains what can be cut to hit it (and what that means for quality or scope).
7) No performance or reliability targets
Red flag: The proposal doesn’t define what “fast” or “stable” means. For AI, it may also ignore latency and cost spikes.
What good looks like: Targets like Core Web Vitals, crash-free sessions, API response time, uptime expectations, and how these are measured (monitoring/alerting). For AI: timeouts, fallbacks, and cost controls (rate limiting, caching, usage caps).
8) AI “magic thinking” (“Just add GPT”)
Red flag: The proposal treats AI as a drop-in feature without defining evaluation, safety, or operations. The result is often unpredictable outputs, unhappy users, and surprise bills.
What good looks like: A clear use case (what problem is AI solving?), an evaluation plan (how you’ll judge quality), a fallback UX (what happens when AI is wrong or unavailable), and a plan for iteration. Many successful AI features also include human-in-the-loop workflows for edge cases.
9) No deployment, DevOps, or handover plan
Red flag: Launch is described as “we’ll deploy it” with no mention of environments, rollback, backups, or documentation.
What good looks like: A practical release plan: CI/CD, dev/stage/prod environments, backups, logging, and a rollback strategy. A handover package should include documentation, runbooks, and basic training for your team.
10) Maintenance is vague or positioned as “optional”
Red flag: After launch, the proposal becomes unclear: who patches vulnerabilities, updates dependencies, monitors uptime, or fixes urgent bugs?
What good looks like: A realistic post-launch plan with response times, a support process, and how ongoing work is prioritized (bugfix vs roadmap). Even a small app needs security updates, platform changes (iOS/Android), and dependency maintenance.
What to do if you spot these red flags
Not every red flag means you should walk away-sometimes it simply means the proposal is incomplete. The key is to ask for clarification in writing. Strong teams don’t mind being asked to define scope, security, testing, ownership, and operational responsibility.
A good proposal doesn’t just promise delivery. It reduces risk, makes tradeoffs explicit, and sets you up to improve the product after launch.
If you’d like to sanity-check a proposal you’ve received-or want help writing an RFP that vendors can quote accurately-get in touch with Jensen Technologies. We’re happy to discuss your goals and help you choose the safest, most cost-effective path for your business.