Red Flags When Hiring a Software Development Agency

Most software development engagements that go badly show warning signs in the sales process. The founders who get burned usually saw them. They explained them away, or they were under time pressure, or the price was right and they hoped for the best.

This is a list of what to watch for. Not theoretical risks — patterns that consistently precede bad outcomes.

They Can't Say No to Scope

In the sales process, a good agency will push back on things. They'll tell you a feature is more complex than you think. They'll question an assumption in your spec. They'll say they've seen that approach fail before and suggest a different one.

An agency that agrees with everything you say is not confirming that you have a perfect plan. It's telling you something about how they work. Either they don't have the experience to know where the problems are, or they know and they're choosing not to tell you because saying yes is easier than having a hard conversation before a contract is signed.

That behaviour doesn't change after the contract is signed. If they won't push back in the sales process, they won't push back when a requirement is underspecified or when a timeline is unrealistic. You'll discover those problems later, when they're more expensive to fix.

The Quote Came Back Too Fast

A detailed quote for a complex project takes time to produce. It requires understanding the requirements, identifying the unknowns, thinking through the architecture, and estimating honestly. That process takes days, sometimes a week or more for anything non-trivial.

A quote that comes back within hours of a first conversation is one of two things: a rough number based on a project size category, or a number worked backwards from what they think you want to hear. Neither is a reliable basis for a contract.

The speed of the quote correlates with how well they've thought through what you're actually building. A slow, detailed quote with questions and assumptions documented is more trustworthy than a fast one — even if the number is higher.

The People in the Sales Meeting Won't Be the People Doing the Work

This is common in larger agencies and offshore firms. The team you meet during the proposal process — articulate, senior, easy to talk to — is the team that wins business. The team that actually builds your product may be entirely different people at a different experience level, sometimes in a different country.

Ask directly: who will be working on this project day to day? Can I meet them before we sign? A good agency will say yes without hesitation. A problematic one will deflect — "the team will be allocated once we start" is the answer to watch out for.

You're entering a working relationship that will last months. You're entitled to know who you're working with.

No Questions About IP and Code Ownership

You should own the code that gets built for you. That should be explicit in the contract — the IP transfers to you on payment, you get access to the repository, you can take the work to another developer if the relationship ends.

Some agencies hold code ownership as informal leverage. Not maliciously, necessarily — it's sometimes just an oversight in their standard contract. But an agency that hasn't thought carefully about IP ownership in their standard terms is an agency that hasn't thought carefully about what happens when an engagement ends badly. And some engagements end badly.

Read the contract on this point specifically. If it's ambiguous, ask for clarification before you sign, not after.

Vague Answers to Technical Questions

If you're a non-technical founder, it can be hard to evaluate technical answers. But you can evaluate whether the answers are specific.

"We use modern best practices" is not an answer. "We'll build this as a monolith to start, move to microservices once the data model is stable" is an answer. "We take security seriously" is not an answer. "We run OWASP checks in the CI pipeline and do a penetration test before launch" is an answer.

Vague technical answers in the proposal process usually mean one of two things: the team doesn't have strong opinions because they don't have strong experience, or they have a standard approach they apply to everything regardless of whether it fits. Neither is reassuring for a project with specific requirements.

The question isn't whether you can evaluate the technical answer — it's whether the answer is specific enough to be evaluated at all.

They Discourage You From Talking to Past Clients

References matter. Not the testimonials on the website — those are selected by the agency and written to be positive. References you can call, who can tell you honestly what the engagement was like, what went wrong, how the agency handled it.

A confident agency will give you references without hesitation. An agency that doesn't have references they're comfortable with, or that actively steers you toward case studies rather than conversations, is an agency that doesn't fully trust what those conversations would reveal.

Ask for two or three references from projects similar in scale and complexity to yours. If they can't provide them, treat that as information.

The Discovery Process Is Optional

Good software development starts with a discovery phase — a structured period of requirements gathering, architecture planning, and spec writing before the build starts. This phase has a cost, and agencies that skip it or offer to fold it into the build are usually doing so because it's a selling point ("start building faster") rather than because it's good practice.

Discovery done properly surfaces assumptions, identifies risks, and produces a spec that the estimate can be based on accurately. Discovery skipped means the estimate was based on your initial description of the project — which is almost always incomplete. The scope that was unclear at the start becomes scope change during the build, and scope change is how fixed-price projects become expensive.

Evaluating an agency's process is as important as evaluating their portfolio. How they approach the beginning of a project tells you a lot about how they'll handle the middle and the end.

What Good Looks Like

For contrast: a good agency asks hard questions early. They document their assumptions. They give you a clear picture of what's in scope and what's not, and they're specific about what happens when something is unclear. They introduce you to the people who will actually do the work. They have clients you can call. Their contract is clear on IP. Their timeline has buffer for the unknowns they know they'll find.

None of this is a guarantee of a perfect project. Software development has genuine uncertainty and good agencies fail sometimes too. But the agencies that handle failures well are also the ones that handle the pre-contract process well. The rigour is consistent.

The warning signs in the sales process aren't proof of a bad agency. They're the signal that the agency either hasn't thought carefully about the work, or has thought carefully and is choosing not to tell you something. Both of those deserve more investigation before you sign.

Armin Marxer writes at zeroclue.dev.