A polished website, an impressive client list, and a competitive quote are the three things most enterprises use to shortlist software development vendors. None of them reliably predict what delivery will look like.
The signals that actually matter — the ones that separate vendors who ship reliable production software from vendors who ship something that works in the demo — tend to show up in less obvious places. Here are nine patterns worth looking for before you commit.
1. No technical architect involved before the quote
If your first point of contact is a business development representative who can quote you a number without involving an engineer, that number was produced without real technical assessment. Any vendor capable of quoting accurately needs an architect who has reviewed your requirements and asked clarifying questions about your existing systems, compliance requirements, and expected scale.
A quote produced without technical review is either padded with a large contingency buffer or dangerously optimistic. Neither serves you.
2. Vague answers on IP ownership and source code access
You should own the intellectual property produced during your engagement — all of it, unconditionally, from the first day of delivery. If a vendor hedges on this, cites "proprietary frameworks," or requires you to stay with them to maintain the codebase, that's a structural dependency being engineered into your contract, not a technical necessity.
Any vendor who can't confirm full IP assignment and source code access before you sign is a vendor to avoid.
3. No mention of testing, code review, or CI/CD in their process
Ask a vendor to walk you through how code gets from a developer's machine into production. A mature team will describe: code review by peers or senior engineers, automated tests that run on every commit, a staging environment that mirrors production, and a deployment pipeline that reduces human error at release time.
A vendor who describes none of these — or describes them as optional add-ons rather than standard practice — is telling you something important about the quality of what they'll deliver.
4. Portfolio is all logos, no specifics
A vendor's portfolio should tell you what problems they solved, not just whose logos they're allowed to display. Ask for specifics: what did the system need to do, what was technically complex about it, and what would the client tell you if you called them?
If a vendor can't give you specifics on at least three projects similar in type or complexity to yours, their portfolio is a marketing artifact, not a proof of capability. Ask for references and call them.
5. Pricing that seems too good relative to scope
Software development has a genuine cost floor. A team capable of building reliable, maintainable enterprise software has experience, and experience costs money. If a quote is dramatically cheaper than others you've received, there are three possibilities: the vendor has fundamentally misunderstood the scope, they plan to cut corners on quality, or they'll recover the margin on change orders after you're committed.
None of those outcomes serves your budget or your timeline.
6. No defined escalation process
Ask what happens when something goes wrong — a missed milestone, a quality issue, a disagreement about scope. A mature vendor has a named account owner, a defined escalation path, and a clear process for issue resolution. A vendor who gives you a vague answer about "open communication" has no formal process, which means disputes get handled informally, slowly, and inconsistently.
7. Reluctance to do a paid discovery phase
Discovery — the process of properly scoping requirements, mapping integrations, and producing an architecture before committing to a full build — typically takes two to four weeks and costs a fraction of the total project budget. Any vendor willing to skip discovery and jump straight to a fixed-price build contract is either very confident in their estimates or not worried about what happens when the scope turns out to be larger than quoted.
Paid discovery is in your interest, not just the vendor's. It's the stage at which you find out whether the vendor's estimates were grounded in reality.
8. No post-launch support model
Every production system requires ongoing maintenance — security patches, dependency updates, performance monitoring, bug fixes. Ask how the vendor handles this after the initial build is complete. If they don't have a defined support model, you'll be negotiating that under pressure after launch, when you're in the least advantageous position.
9. They agree with everything you say
A vendor who never pushes back on your requirements, never identifies potential technical challenges, and never suggests that your approach might create problems downstream is either not thinking critically about your project or not confident enough to tell you things you don't want to hear. Both are problems.
The vendors worth working with are the ones who identify risks you hadn't considered — not to complicate the sale, but because they've seen similar projects fail for the same reasons.
Evaluating development partners right now?
We're happy to answer any of these questions directly — about our process, our IP terms, our escalation model, or anything else on this list.
Schedule a Discovery CallRelated: How to estimate software development costs before you talk to vendors · Frequently asked questions about working with Webworx Asia