Red flags when hiring a software development agency
Over the years we have watched founders lose time and money to development agencies more than once, and it is almost always the same story. The pitch is polished, the deck is confident, and six months later the founder is paying us to rebuild something that never should have been released the way it was. The cost is rarely just money. It is the months you lose redoing work, and the lost progress that takes longer than planned to recover. Here is what we tell people to check before they sign anything. Most of these red flags, meaning warning signs, are visible in the first two or three conversations, if you know where to look.
None of what follows requires you to be technical. It requires you to ask direct questions and pay attention to how clearly the answers come back.
They cannot name who writes the code
Many agencies present their most senior people in the sales process, then staff the actual project with whoever happens to be free that month. The person who impressed you in the sales call disappears after the contract is signed, and a changing group of contractors you never met inherits your product.
So ask directly: who, by name, are the engineers on this project, and what have they personally delivered before? A confident partner will answer without hesitating. They will tell you the lead engineer's name, explain how the team is organized, and be honest about who is senior and who is learning. A vague answer built around "our team" instead of named individuals is worth taking seriously as a warning.
We have seen the cost of this happen. When the people who scoped the work are not the people who build it, the understanding of the problem gets lost in the handoff. Decisions that felt obvious in the sales meetings get reinvented badly three weeks in. The fix is simple: insist on continuity between the people who sell and the people who build, and get it in writing if you can.
Their first deliverable is a document, not software
A team that understands your problem proposes a small, concrete first phase: something working you can look at within the first couple of weeks. It might be rough. It might be one screen and one real workflow. But it runs, and it tells you more about whether this partnership works than any slide ever could.
If what they propose instead is a lengthy strategy document or a discovery phase that produces only diagrams, you are probably talking to consultants, not builders. There is a place for strategy work, but you hired an engineering partner to deliver software. In our work the fastest signal of a healthy engagement is how quickly we can show real software to the client. Early working code brings up the hard questions early, when they are cheap to answer, instead of at the end, when they are expensive.
Ask any agency what you will be able to see and use two weeks after kickoff. The specificity of the answer tells you almost everything.
They want a large payment before any milestone
Reasonable engagement terms tie payment to delivery: a working part of the product, a completed phase, a tested release you can actually run. A large upfront payment with no defined milestone shifts all the risk onto you before you have seen a single line of working code.
We understand that a partner needs commitment too, and some deposit is normal. What is not normal is a structure where you have paid a big share of the total before there is anything to evaluate. Payment tied to milestones keeps both sides honest. It gives you a natural checkpoint to slow down or stop working together if the work is not what you expected, and it gives a good team a clear reason to prioritize delivering over billing. When an agency resists any link between payment and delivery, that resistance is the answer.
The contract is unclear about code ownership
You should own the code, the architecture decisions, and the documentation, without exception. This sounds obvious, and yet it is one of the most common places founders get stuck.
Read the intellectual property section carefully. Contracts that keep licensing rights with the agency, or that quietly tie your product to their own internal tools, proprietary frameworks, or hosting, give them power they can use against you later. The moment you feel it is usually at renewal, when leaving suddenly means separating your product from infrastructure you do not control and cannot take with you. We have taken over projects where the previous agency owned the deployment pipeline and the founder could not so much as change a setting without paying for it.
Ownership should transfer as work is delivered, not at some final payment far in the future. Ask where the code lives, who has access, and what happens on day one if you decide to stop working together. A partner building for your benefit answers these plainly. A vendor building so you cannot leave gets uncomfortable.
The timeline or price sounds too good
An agency that guarantees an unrealistically fast delivery, or a price well below the market range, is usually skipping necessary work somewhere you will not see until it is too late. The skipped work is often testing, security, or the boring architecture work that keeps a product working once real users arrive.
This one is hard for founders because the too-good number is also the tempting one. But a serious estimate comes with a breakdown, not a single lump figure. Ask to see where the hours go: how much for the core build, how much for testing, how much held back for the unknowns that always appear. When a team can show you the parts of their estimate and explain their assumptions, the number is trustworthy even when it is higher than you hoped. When they cannot, the low price is not a discount. It is a promise they have no plan to keep.
They talk about your industry in generalities
A partner who has actually delivered software in your industry asks more precise, more specific questions about your business than you expected. They know where the hard parts are: the unusual compliance case, the integration everyone underestimates, the workflow that looks simple and never is. They can point to work in adjacent domains and explain what carried over and what did not.
Vague familiarity with "startups" or "SaaS" in general is not the same thing. Watch how they respond when you describe your problem. Do they agree with everything and repeat your own words back to you, or do they challenge you, correct a wrong assumption, and tell you which part will be harder than you think? The second kind of conversation is the one you want. It is uncomfortable in the moment and it saves you months later.
What this looks like done right
None of these checks require special technical expertise, just direct questions and attention to how clearly the answers come back. Put them all together and the pattern is consistent: a good partner is specific where a bad one is vague, and comfortable giving exact commitments where a bad one avoids the question.
We built our own process around avoiding exactly these failure modes, from milestone-based delivery to full code ownership from day one to continuity between the people who scope and the people who build. You can see how we scope and staff a full product build or a staff augmentation engagement in detail, or a wider view of our custom software development work.
For the fuller version of this evaluation, see how to choose the right external development team, or the specific comparison of software development partner vs. vendor if you are trying to name the exact behavior these warning signs point to.
Choosing a development partner is one of the most important decisions a founder makes, and the good news is that the signs are visible early. Ask the direct questions, listen for the clear answers, and trust the discomfort when the answers do not come.
Related guide: How to choose a software development partner.
There is a new warning sign worth adding, and it has two opposite forms. The first is a supplier who will not say how much of your code a model will write, or who implies the question is somehow rude. The second is a supplier who treats AI writing the code as the whole answer and cannot describe what happens between the model producing a first draft and that draft serving real users. Both come from the same failure: no clear account of who is accountable for the output. Ask who will have read the change before it reaches your branch, and expect a name rather than a process diagram.
