The difference between a software project that ships and one that burns $150,000 before getting cancelled is almost never the technology. It is the vendor. And the warning signs that predict failure are visible before the contract is signed, in how the company estimates, who shows up to meetings, and what they do not mention.
After 8 years and 50+ projects, the patterns are consistent. Companies that fail on delivery share the same structural problems, and those problems are detectable during the sales process if you know what to look for.
Red flag #1: The estimate arrives too fast
A company that sends a fixed-price estimate within 48 hours of your first conversation has not done the work to understand your project. They have a pricing formula (X screens times Y hours times Z rate) and they applied it to whatever you described.
A real estimate for a $50,000+ software project requires understanding the business rules, the data model, the integration points, and the edge cases. That takes a discovery process: 3 to 5 days for a focused project, 2 to 3 weeks for an enterprise system. If the vendor skips this, they will either underestimate and cut corners during delivery, or overestimate by 40% to cover their uncertainty. Neither outcome is good.
What to look for instead: a vendor that responds to your initial request with questions, not a quote. Questions about your business process, your existing systems, your team structure, and your definition of success. The estimate should follow a discovery conversation, not precede it.
Red flag #2: No technical person in the sales process
If every call is with a sales representative or account manager and you never speak to the person who will architect or lead the development, the company has separated sales from delivery. This means the person making technical promises has no accountability for keeping them, and the person who will build the software has no input into what was promised.
This pattern is common at agencies with 50 to 200 people. The sales team sells a vision. The delivery team inherits a scope document they had no part in writing, with a timeline they did not agree to. The project starts with a gap between what was sold and what is buildable within the budget.
What to look for instead: the technical lead or architect joins the second or third call. They ask questions about your data, your systems, and your constraints. They push back on scope or timeline if it does not make sense. Pushback during sales is a sign of engineering honesty, not a negative signal.
Red flag #3: They agree to everything
"Can you integrate with our legacy ERP?" Yes. "Can you have an MVP in 6 weeks?" Absolutely. "Can you add AI-powered analytics to the dashboard?" Of course. A company that agrees to every requirement without qualifying scope, timeline, or trade-offs is not confident. It is desperate for the contract.
Real engineering requires trade-off conversations. A 6-week MVP means cutting features. An ERP integration means understanding the ERP's API limitations before committing. AI analytics means defining what "AI" actually does in your context, not adding a buzzword to the proposal.
What to look for instead: a vendor that says "we can do X, but it adds 3 weeks and $15,000 to the scope" or "we recommend building without that feature first and adding it in phase 2 after you have user data." Trade-off conversations during sales predict trade-off conversations during delivery, which is where projects succeed or fail.
Red flag #4: The portfolio is all design, no systems
A portfolio page showing 30 projects with screenshots of landing pages, mobile app UIs, and eCommerce storefronts tells you the company builds interfaces. It does not tell you they can build the backend logic, integrations, and data architecture that make enterprise software work.
The hard part of a CRM, ERP, or operations platform is never the UI. It is the business rule engine, the permission model, the audit trail, the reporting layer, and the data migration from the legacy system. If the portfolio does not mention these, the company may not have built them.
What to look for instead: case studies that describe the problem solved, the technical decisions made, and the measurable outcome. "We reduced paper-based approvals by 90% for a publicly listed telecom company by building a custom procurement platform with role-based workflows and audit logging" tells you more than a screenshot grid.
Red flag #5: No CI/CD, no code reviews, no process documentation
Ask the vendor: "Walk me through what happens when a developer finishes a feature." If the answer does not include code review by another engineer, automated testing, and a deployment pipeline that moves code from development to staging to production, the company ships code directly from a developer's laptop. This works for a 2-person project. It fails catastrophically at scale.
The absence of engineering process becomes visible 3 to 6 months into a project: bugs that were fixed reappear because there are no regression tests, features break other features because there is no integration testing, and deployments happen on Friday afternoons because there is no release process. By then, switching vendors means restarting with a codebase that no one wants to inherit.
What to look for instead: ask for a demo of their development workflow. A company with real process can show you their CI/CD pipeline, their code review tool (GitHub, GitLab, Bitbucket), their project board, and their deployment history. If they cannot show these in 10 minutes, they do not exist.
Red flag #6: The team is assembled after you sign
"We will assign the right team once the contract is signed." This means the company does not have the team today. They will recruit contractors, pull developers off other projects, or hire from a subcontracting network. The team that starts your project may not be the team that finishes it.
Contractor-assembled teams have higher turnover. A developer who is a contractor on your project has no long-term relationship with the codebase, the client, or the company. When a better contract appears, they leave. Knowledge walks out the door. The replacement developer spends 2 to 4 weeks understanding the codebase before being productive, and the cycle repeats.
What to look for instead: ask to meet the specific engineers who will work on your project before signing. Ask how long they have been with the company. Ask about the last project they completed together. A team that has worked together on two or three projects will outperform a newly assembled team every time.
Red flag #7: Communication goes silent between milestones
During the sales process, responses come within hours. After the contract is signed, updates arrive every two weeks in a formal status report. Between reports, you have no visibility into what is being built, what is blocked, or whether the project is on track.
This pattern hides problems. A two-week status report can say "on track" while the team is stuck on a technical blocker they have not escalated. By the time the problem surfaces in a milestone review, two weeks of budget have been spent going in the wrong direction.
What to look for instead: ask about their communication cadence during the sales process. Daily async updates (Slack or equivalent), weekly demo calls where you see working software, and access to the project board where you can see what is in progress. A company that resists giving you project board access is hiding how work actually moves through their team.
Red flag #8: They have never said no to a client
Ask the vendor: "Tell me about a project you turned down, and why." If they cannot answer this question, they take every project that comes through the door. A company that takes every project regardless of fit will say yes to yours too, even if your requirements do not match their expertise.
A company that has turned down work has enough deal flow to be selective. Selectivity means they take projects where they can deliver well, which means your project gets a team that has relevant experience instead of a team that is figuring it out on your budget.
Red flag #9: The contract locks you in with no code access
If the contract does not specify that you own the source code and have access to the repository from day one, the vendor controls your project. If the relationship deteriorates, you cannot take the code to another team without a legal fight. This happens more often than buyers expect.
Code access is also a quality signal. A vendor that gives you repository access from the first sprint is confident in their code quality. A vendor that delivers code only at milestones may be cleaning up before each delivery, which means the day-to-day codebase is messier than what you see.
What to look for instead: the contract should state IP assignment upon payment, continuous repository access (not milestone-based), and documentation sufficient for another team to continue the work. These are standard terms for any serious software engagement.
How do you evaluate a software development company?
Question to Ask | Red Flag Answer | Green Flag Answer |
|---|---|---|
How do you estimate projects? | "We can give you a ballpark right now" | "We need a discovery phase before we can estimate accurately" |
Who will build this? | "We will assign the right team after signing" | "Meet the lead engineer and architect who will own your project" |
What is your development process? | "We use Agile" (with no specifics) | "Here is our CI/CD pipeline, code review process, and deployment workflow" |
Can you add feature X? | "Yes, absolutely" (no trade-off discussion) | "Yes, but here is the scope and timeline impact" |
How will I see progress? | "We send monthly status reports" | "Daily async updates, weekly demos, full project board access" |
Who owns the code? | "We will discuss IP after the project" | "You own the code. Here is the IP clause in the contract. You get repo access from day one." |
What does a trustworthy software development company look like?
The inverse of every red flag above. They estimate after discovery. Technical leadership is present in sales. They push back on scope when it does not make sense. Their portfolio shows systems, not screenshots. They have documented engineering processes. Their team is stable and assigned before the contract. Communication is daily, not monthly. They have turned down projects. And you own the code from day one.
None of these signals require you to evaluate technical quality directly. You do not need to read code or assess architecture to spot a bad vendor. The red flags are structural and visible in how the company sells, communicates, and contracts.
Need a team to build this for your business?