We’ve been on both sides of vendor-buyer conversations — as the vendor building for clients, and as the buyer evaluating other vendors when our own team needs specialist help. The patterns of vendors who’ll burn you are depressingly consistent. Here are the six flags we’ve learned to listen for before signing anything.
Red flag 1: They won’t share code mid-project
The healthiest vendor engagement gives you push/pull access to the code repository from day one. PRs land into your account; your team can review them; if you decide to part ways, the code is already yours.
Vendors who hold the code on their side until “completion” are protecting themselves from a normal customer right — the right to audit and course-correct as the work goes on. If you can’t see what’s being built, you can’t catch a wrong turn until it’s permanent.
Red flag 2: They quote without a written scope
“$50,000 for a SaaS” means “$50,000 for whatever we decide to build.” A real vendor will spend the first 1-2 weeks writing a scope document with you, then estimate the scope, then quote. If you’re getting a number without a spec, the spec is going to drift away from your needs and toward whatever they find easiest to build.
A defensible scope document includes: user stories, screen list, acceptance criteria, integrations, non-functional requirements (perf, security, compliance), and explicitly what’s OUT of scope. Without it, every conversation later becomes “but we thought that was included.”
Red flag 3: They bait-and-switch engineers
Sales call: a senior engineer who explains the architecture clearly. Project start: a junior who’s never built this kind of thing. The senior you met is now “available for consultation” but doesn’t write code.
Ask explicitly: who will work on this project, day-to-day, in what proportion? Get names in the SOW. If they refuse, walk.
Red flag 4: They’re vague on testing & deployment
Ask: what’s your testing strategy? what does CI/CD look like for our project? what’s the deployment cadence?
Good vendors answer with specifics — “unit + integration tests with at least 70% coverage on the business logic; CI runs on every PR; deploy to staging on merge to main; production canary at 5% before full rollout.” Bad vendors wave vaguely — “we’ll figure it out as we go.” That’s code for “we’ll cut testing first when we’re behind.”
Red flag 5: They want to own the IP
Code you paid for is yours. Always. Any contract that includes “vendor retains intellectual property rights” or “custom modules remain the vendor’s licensed software” is a red flag.
Exception: pre-existing libraries or platforms they bring in (e.g. a vendor-built framework they use across clients). Those they can license to you. But anything built specifically for you should be 100% your IP, with full source-code rights and a perpetual license at minimum. Insist on this in the contract.
Red flag 6: No references they’re willing to share
“We can’t share client names due to NDAs.” Some of this is real — especially for early-stage product work. But a vendor who can’t put you on the phone with ANY of their last 3 clients has a tell. Confident vendors put you on calls with the technical lead at the client side; they let you ask the uncomfortable questions.
When you do reference calls, ask specifically: were estimates accurate? Did the team you bought stay the team you got? Would you hire them again? The third question is the most predictive.
The green flags
- They ask hard questions about your business before quoting
- They push back on scope they think is wrong (good ones do this; bad ones say yes to everything)
- Their SOW is specific, with deliverables and acceptance criteria, not adjectives
- They commit to weekly demos, not monthly status reports
- They share their own engineering practices in detail when asked
- They give you direct access to the engineers, not just an account manager
How we approach this
At Dezen we work the way we’d want a vendor to work for us: shared repo from day one, scope doc before estimate, named engineers in the SOW, weekly demos, full IP to the client. Some of this we learned by being on the buying side and getting burned.
Takeaways
- Code visibility from day one. Non-negotiable.
- Scope doc before quote. Always.
- Named engineers in the SOW. No bait-and-switch.
- Testing, CI/CD, deploy — if vague, walk.
- You own the IP. Period.
- Real references, real conversations.
