Rated ⭐ 4.8/5 by 100+ clients
1.Why Most Bad Vendor Decisions Look Good on Signing Day
2.Red Flags in the Sales Process: What the Pitch Reveals
3.Red Flags in the Proposal: Vague Scope, Vaguer Timelines
4.Red Flags in the Contract: Terms That Should Stop You Cold
5.Red Flags Around IP and Source Code Ownership
6.Red Flags in Pricing: When Cheap Becomes Expensive
7.Red Flags in Communication and Team Structure
8.How to Evaluate a Software Development Company Before Committing
9.Questions to Ask Before Signing a Software Contract
10.What a Healthy Vendor Relationship Looks Like From Day On
Nobody signs a bad tech contract knowingly. Every failed vendor relationship started with a confident pitch, a reasonable-looking proposal, and a signing day where both sides felt good about the future.
The problems were visible earlier. They almost always are. The scope was a little vague, the ownership clause was a little one-sided, the team you met in the sales call was not the team that would do the work. But by the time these things surfaced as real problems, months of budget and momentum were already committed.
This guide covers the red flags when hiring a software development company that show up before you sign, if you know where to look. Some appear in the sales process, some in the proposal, and the most expensive ones hide in the contract itself. We build software for a living, so consider this a view from inside the industry: the warning signs we would look for if we were on your side of the table.
There is a structural reason vendor problems stay hidden until it is too late. The sales process is the period when a vendor is most attentive, most responsive, and most flexible. You are evaluating them at their absolute best. Everything after signing regresses toward their actual operating standard.
This means the useful signals are not how impressive a vendor looks at their best. The useful signals are the small inconsistencies that leak through even when someone is trying to impress you. A missed follow-up during the sales cycle. A question they answered around rather than answered. A proposal section that stays vague after you asked for specifics.
The discipline is to treat the pre-signing period as a preview of the working relationship, not as a negotiation to get through. A vendor who is sloppy while trying to win your business will not become precise after winning it.
One more mindset shift helps. Most buyers evaluate vendors on capability: can they build this? That is the wrong primary question, because most established agencies can build most things. The better question is about behaviour under pressure: what happens when scope shifts, when a milestone slips, when you disagree? The red flags below are largely behavioural, because behaviour is what you are actually buying.
The pitch stage feels like theatre, but it leaks real information.
A vendor who agrees to every feature, every timeline, and every budget constraint without pushback is not being flexible. They are deferring the conflict to after signing, when you have less leverage. Honest vendors say no during the sales process. It costs them deals and it tells you they will manage scope honestly later.
If every pre-sales conversation happens with sales staff and you never speak to an architect or senior engineer before signing, you are buying a promise made by people who will not have to keep it. Insist on technical presence in at least one detailed discussion.
A vendor who jumps straight to solutions without probing your users, your constraints, your existing systems, and your definition of success is planning to build what you say, not what you need. The quality of their questions before signing predicts the quality of their thinking after.
Ask directly: which people, at what seniority, for how many hours a week. Vague answers here usually mean a bench-allocation model where your project gets whoever is free.
The proposal is where intentions become commitments, or fail to.
"User management module" is not scope. What a user can do, on which devices, with what edge cases handled, is scope. Feature-list proposals guarantee disputes later, because both sides fill the vagueness with different assumptions.
One big deadline months away means you will discover problems at the end, when they are most expensive. A credible proposal breaks delivery into stages with something reviewable at each stage.
Strong proposals state exclusions explicitly: what is out of scope, what counts as a change request, what post-launch support does and does not cover. A proposal that only describes inclusions is leaving the boundary undefined, and undefined boundaries always get contested.
A 214-hour estimate for a loosely defined project is theatre. So is a perfectly round number that matches your stated budget exactly. Both suggest the estimate was reverse-engineered from what you wanted to hear.
This is where the most expensive problems hide, and where reading slowly pays.
Large upfront payments, or payment dates tied to the calendar rather than to accepted milestones, remove the vendor's financial incentive to deliver. Milestone-linked payments keep both sides honest.
The contract should state how deliverables get reviewed, how long you have to raise issues, and what happens when something fails acceptance. Without this, "done" means whatever the vendor says it means.
Check what happens if you want to leave mid-project: notice periods, kill fees, and critically, what you receive on exit. A contract that is easy to enter and painful to leave is designed that way.
What happens when a bug appears three weeks after launch? A defined warranty period for defect fixes, separate from paid enhancements, should be written down. Vendors who resist this expect to charge you for their own mistakes.
Asymmetric liability clauses are common and negotiable. If a vendor refuses any movement here, note what that says about how they expect things to go.
Ownership deserves its own section because it is the single most expensive thing buyers get wrong, and the damage is often discovered years later, during a funding round, an acquisition, or a vendor switch.
The default assumption to verify: you should own the intellectual property in the custom work you paid for, and ownership should transfer as you pay, not only at final payment of the entire engagement.
Watch for contracts that grant you a licence to use the software rather than ownership of it. A licence means the vendor owns your product and you are renting it. This arrangement has legitimate uses for productised platforms, but it should never be buried in a custom development contract as if it were standard.
You should have ongoing access to the repository from early in the project, not a promised handover at the end. If a vendor hosts everything in their own accounts, from code to cloud infrastructure to domain registrations, switching vendors later becomes a hostage negotiation.
Most agencies reuse internal libraries and frameworks, which is fine and efficient. The contract should distinguish clearly between vendor-owned reusable components, which you receive a perpetual licence to, and your custom IP, which you own outright. Silence on this distinction creates ambiguity that favours the vendor.
If a vendor becomes evasive when you raise ownership, treat that as disqualifying. Established agencies handle these clauses routinely and have nothing to protect by keeping them vague.
Price is the most visible number in the decision and the least informative one.
When five vendors quote in a similar band and one comes in at half, that vendor has either misunderstood the scope or understood it perfectly and plans to recover the difference through change requests. Both outcomes cost you more than the middle quotes would have.
Pure time-and-materials pricing is legitimate for genuinely exploratory work, but it needs guardrails: estimates per feature, burn reports, and approval thresholds. Open-ended hourly billing with none of these is a meter running without a route.
Deployment, third-party licences, testing, project management, post-launch support. A trustworthy proposal surfaces the full cost of ownership upfront, including the costs that are not the vendor's revenue.
The pattern across all pricing red flags is the same: the initial number is designed to win the signature, and the real number emerges afterward, when switching is expensive.
How a vendor communicates before signing is the ceiling, not the floor, of how they will communicate after.
This is the period of maximum vendor motivation. If replies take a week now, imagine month four.
If everything routes through one account manager and you never interact with the people building your product, information is being filtered in both directions. Healthy engagements give you direct access to the technical lead.
Weekly demos, sprint reviews, a shared task board, a named escalation path. Vendors who run disciplined projects describe this structure without being asked, because it is how they already work.
Some agencies sell the project and subcontract the delivery. Subcontracting is not inherently bad, but concealed subcontracting is, because every quality commitment you negotiated was made by people who will not do the work. Ask directly whether delivery happens in-house.
Red flags tell you what to avoid. Evaluation tells you what to confirm. When you evaluate a software development company seriously, four checks matter more than the portfolio.
Speak to references, but ask about problems. Every vendor supplies happy references. The useful question to ask those references is not whether they were satisfied, but what went wrong during the project and how the vendor handled it. Every real project has problems. You are evaluating the recovery, not the absence.
Review something real. Case studies are marketing. Ask to see a live product they built, and if possible, ask how a specific technical decision in it was made. The depth of the answer reveals whether the people in the room actually did the work.
Start small if the stakes allow. A paid discovery phase or a small first module tells you more about a vendor in three weeks than a sales cycle tells you in three months. It also gives both sides a clean exit if the fit is wrong.
Watch how they handle disagreement before signing. Push back on something in the proposal and observe. Defensiveness, instant capitulation, or a reasoned defence of their position: you will see one of these, and it is the one you will live with for the whole engagement.
Take these questions to ask before signing a software contract into your final vendor meeting, and pay attention to which ones produce fluent answers and which produce pauses.
Who owns the intellectual property, and when does ownership transfer? Which parts of the delivery are your pre-existing components, and what licence do we get to those? Will we have repository and infrastructure access from the start, under our own accounts? What exactly happens if we end the engagement midway, and what do we walk away with? How are change requests estimated, approved, and billed? What does the warranty period cover after launch, and for how long? Who specifically will work on this project, and what happens if those people leave? What is the escalation path when we disagree on whether something meets spec?
None of these questions is aggressive. They are the questions experienced buyers ask routinely, and experienced vendors answer routinely. Discomfort with them is itself an answer.
It is worth ending the checklist with the positive image, because the goal is not to approach every vendor with suspicion. It is to recognise the good ones faster.
A healthy engagement starts with the vendor asking more questions than you do. The proposal defines what is excluded as clearly as what is included. The contract reads like it was written for a long relationship: milestone payments, clear acceptance criteria, IP transferring as you pay, and exit terms neither side is afraid of. You know the names of the people building your product, you see progress in working software rather than status decks, and the first disagreement, when it comes, gets resolved through a process both sides already understood.
Vendors like this exist in every market and at most price points. The red flags in this guide are not for avoiding the whole industry. They are for clearing the noise quickly so you can find these vendors and move.
At Autuskey, we have spent over a decade on the vendor side of this table, working with clients across India, the UK, Europe, and Australia. That experience shaped how we structure engagements, and the structure looks like the healthy relationship described above because that is the only kind that lasts a decade.
Our engagements begin with a discovery phase that produces a scope document defining behaviour, exclusions, and acceptance criteria before any long-term commitment. Payments link to milestones, clients get repository and infrastructure access under their own accounts from the start, and intellectual property in custom work transfers as it is paid for. Where our internal accelerators are used, the contract says so explicitly, with a perpetual licence attached.
We would rather lose a deal during honest scoping than win it through a vague proposal. That trade has served our clients well, and it has served us better.
If you are evaluating vendors for an upcoming project and want a second opinion on a proposal or contract you have received, that is a conversation we are glad to have, whether or not we end up building it.
Bad vendor relationships are rarely caused by bad engineers. They are caused by vague scope, one-sided contracts, hidden costs, and communication structures that filter out the truth, all of which were visible before signing to anyone who knew where to look.
Now you know where to look. Read the proposal for what it excludes. Read the contract for ownership, acceptance, and exit. Watch the sales process for how the vendor behaves when you push back. The hour you spend on this before signing is the cheapest hour of the entire project.
Let's have a word to understand how we can help you in improving your website. Just drop us an email and we will get back to you as soon as possible.
CONTACT US
Partner with Autuskey to build a remote, Agile software development team.
Rated ⭐ 4.8/5 by 100+ clients
