A red flag is not a single awkward moment in a conversation. It is a pattern of behaviour, a gap in process, or a contractual position that raises the probability of a project going wrong. For business-critical web applications — CRMs, customer portals, internal tools, SaaS products—the consequences of a poor supplier choice extend well beyond a delayed launch. You may end up with a system you cannot maintain, data you cannot extract, or a dependency you cannot escape.
The difficulty is that red flags often appear reasonable at first glance. A supplier who promises a fixed price for an uncertain scope sounds reassuring until you realise that certainty was manufactured by ignoring the unknowns. A team that skips detailed discovery in favour of "getting started quickly" may simply be deferring the hard questions until you are financially committed and operationally reliant.
Red flags also depend on context. A one-person studio might be perfectly suited to a small internal tool with a narrow brief, but a serious risk for a multi-tenant SaaS platform requiring ongoing scaling, security reviews and team continuity. The same characteristic—small team size—signals different things in different situations. This is why checking for red flags means matching what you observe against what your project actually demands, not against a generic list of supplier sins.
Red flags and the evidence that resolves them
| Signal | What would reduce the concern |
|---|---|
| Instant certainty on vague scope | A discovery plan, explicit assumptions and a range rather than invented precision. |
| Unclear delivery team | Named roles, availability and disclosure of subcontracting. |
| No acceptance method | Testable criteria, review points and defect handling. |
| Supplier-controlled critical accounts | A documented account and access model under business control where appropriate. |
| Resistance to exit planning | Clear handover, data export, repository and transition obligations. |
Replacing spreadsheets with a web application
When a business is moving from spreadsheets to a proper application, the supplier needs to understand the existing process in detail before proposing a solution. A red flag in this scenario is a supplier who presents a technical architecture or a feature list after a single conversation, without walking through the actual data, the exceptions, the handoffs between roles and the points where the current spreadsheet breaks down. If they are not curious about the messy reality of how work happens, they will build something that looks clean in a demo but fails in daily use.
Building a customer portal
Portals involve external users, authentication, document access and often integration with back-office systems. A supplier who does not ask early questions about user roles, permission boundaries, session management and what happens when a user forgets their password or loses access is showing a gap in their thinking. Another warning sign is treating the portal as a purely front-end exercise without discussing where the data lives, who owns it and how it stays in sync with other systems.
Modernising a legacy system
Legacy modernisation carries specific risks around data migration, business continuity and hidden dependencies. A red flag here is a supplier who proposes a full rebuild without first conducting a structured audit of the existing system—its data model, its undocumented workflows, its integration points and the assumptions baked into the code. Equally concerning is a supplier who dismisses the legacy system outright without being able to explain what it currently does well, what data it holds and what regulatory or operational constraints govern any transition.
Developing a SaaS product
For SaaS, the supplier needs to think beyond the first release. Red flags include no discussion of multi-tenancy architecture, no consideration of how billing and subscription states will be managed, and no plan for how the product will be supported and iterated after launch. A supplier who treats a SaaS build as if it were a one-off project with a fixed end date misunderstands the nature of the product.
Mistaking confidence for competence
A supplier who answers every question immediately and never pauses to think may simply be unwilling to admit uncertainty. In web application development, honest answers often start with "that depends" or "we would need to look at the data model first." A pattern of instant, definitive answers to complex questions—especially around integration, data migration or performance—should prompt closer scrutiny, not relief.
Accepting vague acceptance criteria
If a supplier's proposal or contract does not define what "done" looks like in testable terms, you have no objective way to confirm the work. Vague descriptions like "the system will be user-friendly" or "all features will work correctly" are not acceptance criteria. A red flag is resistance when you ask for specific, verifiable conditions—for example, "a user with the Viewer role cannot edit records, and attempting to do so returns a permission error within two seconds." If a supplier frames this level of detail as unnecessary bureaucracy, that is a meaningful signal about how they manage scope and quality.
Unclear position on source code and asset ownership
Some suppliers treat the code they write as their intellectual property, licensing it to you rather than transferring ownership. This is not inherently wrong, but it must be discussed openly and early. A red flag is a contract that is silent on ownership, or a supplier who deflects the question with reassurances rather than a clear written position. You need to understand what you will own, what you will have a licence to use, and what happens to the code, the infrastructure and the deployment pipelines if the relationship ends.
No mention of data migration or exit planning
For any system that will hold business data, the supplier should be able to explain how data gets in, how it is structured, how it is backed up and how you would get it out. A red flag is a supplier who never raises these topics and who has no ready answer when you ask. Exit planning is not pessimism; it is basic risk management. If a supplier treats questions about data portability as a sign of distrust, that tells you something about the dynamic they expect in the relationship.
Do not turn a warning list into a mechanical score
Checking for red flags is a filtering exercise, not a selection method. It helps you eliminate suppliers who are clearly unsuitable, but it does not tell you which of the remaining options is the right fit. A supplier with no obvious red flags may still be a mediocre match for your specific project, team and operating model. Red flags are most useful early in a selection process, before you invest time in detailed discovery meetings or commercial negotiations.
Evidence to collect before appointment
- Ask who will actually be doing the work. If the people in the pitch meeting are not the people writing the code, understand the handoff and how quality is maintained.
- Ask how they handle changes to requirements after development has started. A supplier who claims there will be no changes is not being realistic; one who has no process for managing them is unprepared.
- Ask what happens if a key person leaves their team during your project. A supplier with no continuity plan is carrying a single point of failure that you cannot control.
- Ask how they test their work and what evidence they provide. "We test everything" is not an answer. You are looking for a description of their approach—unit testing, integration testing, user acceptance testing—and how they document the results.
- Ask about their support model after launch. A supplier whose engagement ends on launch day is leaving you with a live system and no safety net.
The purpose of checking for red flags is not to find a flawless supplier. It is to avoid entering a relationship where the structural problems are visible from the outset but ignored because the pitch was polished or the price was attractive. Most red flags, when spotted early, lead to better questions—and better questions lead to better decisions.
How to use red flags sensibly
- Look for patterns rather than punishing one imperfect phrase.
- Ask for clarification and evidence before drawing a conclusion.
- Distinguish an honest limitation from evasiveness.
- Record material risks and how the contract or delivery plan addresses them.
- Do not let a low price cancel risks that remain unresolved.