I build software for a living, on the vendor side of the table, which means I've also watched competitors and peers hide problems from clients in ways that are completely predictable once you know what to look for. Software vendor red flags rarely show up in the pitch deck. They show up in the small procedural details vendors would rather you not ask about, because the honest answer reveals how much control you're about to give up.

Most failed software projects I've been called in to rescue didn't fail because the vendor lacked technical skill. They failed because the client never asked the questions that would have exposed a structural problem before signing, and by the time it surfaced, the relationship, the budget, and months of runway were already spent.

Here's the checklist I'd want a client to run through before they sign with anyone, including a company like mine.

Red Flag 1: No Staging Environment You Can Actually See

If a vendor can't show you working software in a staging environment before final payment milestones, ask why. A credible vendor demos progress continuously, not just at the end. If every update is a slide deck or a verbal status report instead of a link you can click, that's not a communication style, it's often a sign there's less built than claimed. Ask for a staging URL in the contract, updated on a fixed cadence, not "when it's ready."

Red Flag 2: Vague or Missing Source Code Ownership Terms

This is the single most consequential clause most SMEs skip. Who owns the source code once the project ends? Some vendors write contracts where the client owns "the deliverable" but the vendor retains rights to underlying frameworks, components, or the full codebase if payments lapse or the relationship ends early. Ask directly: if we stop working together tomorrow, do we get full, unencumbered source code and the right to hand it to any other developer? If the answer is hedged, that's the vendor preserving leverage over you for the life of the product.

Red Flag 3: Hourly-Only Pricing With No Estimate Ceiling

Hourly billing itself isn't a red flag, open-ended hourly billing with no estimate range is. A vendor confident in their scoping process can give you a range (not a false-precision fixed price, a range) and flag when actual hours are trending past it. A vendor who refuses to give any ceiling, or gets defensive when you ask for one, either hasn't scoped the work carefully or is deliberately keeping the meter running without accountability.

Red Flag 4: No Named Technical Lead You Can Actually Talk To

If every technical question gets routed through an account manager who "will check with the team," you don't have access to the person making architecture decisions, you have a filter between you and them. Ask who the technical lead on your project is, by name, and ask to speak with them directly at least once before signing. Vendors that keep clients at arm's length from the actual builders are often doing so because the builders are junior, overseas subcontractors with no continuity, or simply don't exist yet.

Red Flag 5: Handover Documentation Treated as an Afterthought

Ask specifically what happens at project handover: what documentation, what access credentials, what deployment runbooks you'll receive. A vendor who has a standard handover package ready to describe in detail has done this before and expects the relationship to end cleanly. A vendor who says "we'll figure that out when we get there" is telling you, in advance, that your exit will be painful. This matters even more if the relationship is going well, because good projects still end eventually, whether by choice or by budget, and the exit terms you never negotiated become the terms you're stuck with.

Red Flag 6: No Discussion of What Happens After Launch

Software isn't a one-time delivery, it accumulates maintenance needs, security patches, and small fixes from day one of production use. If a vendor's proposal is entirely about the build and silent on post-launch support, ask them directly what a bug found in week two of production looks like: response time, cost, whose responsibility. Vendors that avoid this conversation are often planning to disappear right after final payment, leaving you to either renegotiate from a weak position or find someone else to inherit an undocumented codebase.

Red Flag 7: Reluctance to Explain Their Own Stack Choices

Ask why they chose the technologies they're proposing, for your specific case, not a generic answer. A competent vendor can explain trade-offs: why this database over that one, why this framework fits your scale and budget. A vendor who answers with marketing language instead of reasoning ("it's the most modern stack") either doesn't have a real rationale or is optimizing for what's easiest for them, not what's right for you. This is closely related to the pattern I described in the hidden cost of legacy systems in your business: stack decisions made for the vendor's convenience today become your expensive constraint in three years.

Red Flag 8: No References From Projects Similar in Scale

A vendor with impressive case studies but no reference client close to your size or complexity is a mismatch risk. Ask for at least one reference from a project comparable to yours, and actually call them. Ask that reference specifically about the handover, about post-launch support responsiveness, and about whether the vendor's estimates held up. Glowing generic testimonials tell you nothing; a five-minute call with a past client tells you almost everything.

A Compressed Version You Can Use in a Meeting

Question What a bad answer sounds like
Can I see it running in staging today? "We'll show you at the end of the sprint."
Who owns the source code if we part ways? "That depends on the payment status."
What's the estimate ceiling for this scope? "We bill hourly, hard to say."
Who's the technical lead, can I talk to them? "I'll relay your questions to the team."
What does handover documentation include? "We haven't finalized that yet."
What's support like after launch? "Let's cross that bridge later."

The Takeaway

None of these red flags are about technical competence, they're about whether a vendor is structured to protect your interests after the contract is signed, not just before. Any vendor worth working with can answer all seven of these directly, in specifics, without deflecting. If you get vague answers on more than one or two, walk away or renegotiate before you sign, not after the first invoice.