I run a software consultancy, which means I'm often the vendor in the room. That's exactly why I want to write about tech vendor red flags candidly, because I've watched competitors, and occasionally earlier versions of my own team, pitch in ways that predict a painful project months before the contract is even signed. If you know what to listen for, the vendor's own pitch behavior will tell you more than their proposal document ever will.
None of this requires technical expertise to catch. It requires paying attention to how a vendor answers questions, not just what they promise. The vendors who cause the least pain are rarely the ones with the flashiest deck. They're the ones who tell you what won't work as readily as what will.
Here are ten flags, each with the one question that exposes it.
The flags that show up in the pitch
1. No demo environment. If a vendor can only show you slides and screenshots, not a working environment you can click through yourself, be cautious. Ask: "Can I get login access to a sandbox before we sign anything." A vendor with a real product says yes immediately.
2. Timelines with no milestones. "Three to four months" with nothing in between is not a timeline, it's a hope. Ask: "What do we see at week two, week six, week ten." A vendor who has actually delivered projects before can answer this without hesitating.
3. "Everything is possible." This is the single biggest red flag in any vendor conversation. Every real system has constraints, trade-offs, and things that are technically possible but a bad idea. Ask directly: "What would you push back on in this request." If they can't name anything, they either haven't thought it through or are telling you what you want to hear.
4. References who all mysteriously stopped answering. Ask for three references and actually call them, not just skim testimonials on the vendor's website. If a name gets provided but somehow never returns your call, or the vendor seems to steer you away from a specific past client, that client's experience is the one you most need to hear.
5. Fixed price with an unclear scope document. A fixed price sounds safe, until the scope is vague enough that every change you request becomes a "that's out of scope" conversation. Ask for the scope document before the price, and read whether it describes actual features and workflows or just broad categories.
The flags that show up during negotiation
6. Pressure to sign fast for a "special price." Real vendors doing real work don't need artificial urgency, because their pipeline doesn't depend on rushing you. A discount that expires in 48 hours is a sales tactic, not a market condition.
7. Reluctance to put maintenance terms in writing. Ask what happens after launch: who fixes bugs, what's the response time, what's the monthly cost. If this stays vague until after the main contract is signed, you'll negotiate it later from a much weaker position, because by then you're dependent on them.
8. No clear owner on their side. Ask who your single point of contact will be for the life of the project, and whether that person has delivered a similar project before, not just sold one. A vendor who assigns "the team" rather than a named person is setting up an accountability gap.
9. Unwillingness to explain their tech stack choices. You don't need to be an engineer to ask "why this technology and not another, and what happens if we need to switch vendors later." A vendor confident in their choices explains the reasoning plainly. A vendor hiding behind jargon is often hiding uncertainty.
10. No mention of what happens if the project fails partway. Ask what the exit terms are: who owns the code, what's delivered if the relationship ends at 60 percent complete. A vendor who has never considered this question hasn't managed enough real projects to know it matters.
Why these flags predict what they predict
Each of these behaviors maps to a specific failure mode later. Vague timelines predict scope creep, because nobody agreed on what "done" looks like at each stage. "Everything is possible" predicts a system that technically does what was asked but is unpleasant to actually use, because trade-offs weren't surfaced early. Missing maintenance terms predict an expensive renegotiation six months after launch, when you have no leverage left.
I've seen a multifinance company get burned by exactly the fixed-price-vague-scope combination: the initial number looked attractive, and by month four, every requested adjustment came with a separate change order and a fresh invoice. The contract was technically honored. The relationship still felt like a bait and switch, because the scope document never described what "complete" meant in enough detail to hold anyone to it.
The one meeting that reveals the most
If you only have time to test one thing, ask the vendor to walk you through a project that went badly and what they changed afterward. A vendor with real delivery experience has a specific, honest answer. A vendor still building their pitch has a story about a "difficult client" instead. That single question tells you more about how the next eighteen months will go than the entire proposal document.
The practical takeaway
Tech vendor red flags are rarely hidden. They show up in how confidently a vendor avoids specifics, whether it's timelines, references, maintenance terms, or exit conditions. Ask the ten questions above before you sign anything, and treat a vague or evasive answer to any single one as reason to slow down, not reason to assume good faith. This checklist pairs well with the broader question of whether you should be building custom at all, covered in Build vs Buy Software: A Decision Framework for Owners, and if the vendor conversation is specifically about an AI feature, the same discipline applies with a few extra questions, laid out in From AI Pilot to Production: A Checklist That Works. If you want a second opinion on a proposal before you sign, that's a conversation worth having at /partner.