Why hiring the wrong agency is expensive twice
The obvious cost of a bad agency hire is the invoice. You paid for work that didn't turn out well, and now you have to pay again to fix it or start over. That part is easy to see coming, and it's the one most founders budget a little contingency for.
The less obvious cost is time. Most founders don't realize an engagement isn't working until several weeks or months in, after sprint reports have come and gone and the product still doesn't feel close to done. There's often a stretch where you suspect something is off but keep giving it the benefit of the doubt, because switching teams feels like admitting a costly mistake. That hesitation itself burns weeks.
By the time you accept that it's not working, you've lost the runway you spent waiting, plus the time it takes to find, vet, and onboard a new team. A new agency also needs time to understand a codebase they didn't write, which is rarely as fast as picking up where the last team left off. For an early-stage company, that lost quarter can matter more than the money did.
That's the real reason vetting matters more than most founders treat it. A few extra hours spent checking references and asking pointed questions up front is cheap compared to redoing three months of work with a different team. Treat the vetting process as insurance against the more expensive failure, not as a formality before you get to the part you actually care about.
Questions to ask before signing
A short list of direct questions tends to surface more than a long list of vague ones. Ask these before you sign anything:
- Who exactly will work on the project? Ask for names, roles, and experience level, not "we'll assign someone once we start." If they can't tell you who's building your product, they haven't planned the engagement yet.
- What happens if the scope changes mid-project? Every real project changes scope at least once. You want a clear, pre-agreed process for that, not a conversation you have for the first time when it happens.
- Who owns the code and IP after final payment? This should be explicit and in writing. Some contracts are vaguer here than you'd expect, and it matters enormously if you ever want to switch teams or bring development in-house.
- What does the post-launch support and warranty period actually cover? "Support included" can mean anything from bug fixes only to full ongoing development. Get the specifics: duration, what's included, and what counts as a new request versus a covered fix.
None of these are trick questions. A team that has done this before will have ready answers, often before you finish asking. It's the hesitation, the deflection, or the "we'll figure that out later" answers that tell you more than the words themselves do.
Red flags worth walking away from
Some warning signs show up before you've even signed anything. Worth treating these as deal-breakers rather than minor annoyances:
- A quote with no breakdown of what's included. A single lump-sum number with no line items usually means the scope hasn't actually been thought through, or it's being deliberately kept vague.
- Reluctance to show past work or client references. A legitimate agency wants to show off what it's built. Hesitation, generic case studies with no names attached, or references you can't actually reach are all worth pausing on.
- Pressure to sign quickly. "This price is only good today" is a sales tactic, not a technical constraint. A good agency wants you to make an informed decision, because that's what leads to a project that actually works out for both sides.
- Vague answers about who actually writes the code. Some agencies subcontract development without disclosing it. That's not automatically a problem, but you deserve to know, since it affects quality control, communication, and accountability if something goes wrong.
If an agency can't clearly answer who's building your product, how changes get handled, and who owns the result, you don't have enough information to sign yet.
None of these red flags are automatically disqualifying in isolation. A busy, reputable agency might be slow to pull together references, for instance. What matters is the pattern. One vague answer is worth a follow-up question. Several vague answers in a row, especially about ownership, team composition, or who actually does the work, is worth walking away from entirely.
How to evaluate a proposal properly
A proposal worth taking seriously separates three things clearly: scope, timeline, and cost. Each should map to the other two. If the timeline changes, you should be able to see why, and if the scope grows, the cost should move accordingly. When these three are tangled together into one vague paragraph, it's harder to hold anyone accountable later.
Also pay attention to how specific the proposal actually is. A proposal that reads like generic boilerplate, the kind that could be copy-pasted across any client with a search-and-replace of the company name, is a sign the agency hasn't actually engaged with your project yet. A proposal that references your specific requirements, constraints, and goals means someone did the work of understanding what you're trying to build before pricing it.
It also helps to check what's explicitly excluded, not just what's included. A proposal that lists deliverables but says nothing about what falls outside scope tends to generate disputes later, when something you assumed was covered turns out not to be. The good ones spell out both sides so there's no ambiguity once work is underway.
Fixed price vs dedicated team, and why the agency's suggestion matters
These are the two most common pricing models in software development, and each fits a different kind of project. Fixed price works when requirements are well-defined and unlikely to change much. A dedicated team model works better when the project is exploratory, evolving, or expected to run for a long time with shifting priorities.
What matters is not just which model you pick, but whether the agency recommends one based on your actual project or defaults to whichever model is easiest for them to sell. An agency that suggests fixed price for a genuinely undefined, evolving product is setting you up for scope disputes later, since every change you make will need to be renegotiated as an "extra." One that pushes dedicated team on a small, clearly-scoped project may just be optimizing for a bigger, longer contract rather than what actually fits your needs.
A useful test: ask the agency why they're recommending a particular model for your project specifically, not in general. If the answer is really just "that's how we usually price things," treat that as a mild red flag on its own, layered on top of everything else you're checking.
This topic deserves more space than one section can give it. We've covered the tradeoffs in full detail in a separate post if you want to dig into which model fits your project before your first call with an agency.
What a healthy working relationship looks like once you've hired someone
Vetting doesn't stop once the contract is signed. A few signals tell you early whether the engagement is going well:
- Regular short check-ins. Not six weeks of silence followed by a surprise demo that doesn't match what you expected. Weekly or twice-weekly updates, even brief ones, keep everyone aligned.
- A shared project-tracking tool you can see into. You shouldn't have to ask what's being worked on. A board or tracker you have access to at any time is a basic sign of a transparent process.
- An agency that pushes back on bad ideas. A team that just agrees to everything you ask for isn't necessarily doing you a favor. The ones worth keeping will tell you when a request will cause problems down the line, even if it's not what you wanted to hear.
These signals are worth checking early, ideally within the first few weeks, rather than waiting until launch to find out whether the working relationship actually functions. If check-ins start slipping, the tracker goes stale, or every idea gets a yes with no pushback, those are the same warning signs from the vetting stage showing up after the contract was already signed. Catching them early costs you a hard conversation. Catching them late costs you the project.
If you're still shaping what a good engagement should look like before you commit to one, it helps to see how a team actually structures its process. Our software development services page walks through how we run projects end to end, from scoping through post-launch support, so you have something concrete to compare other proposals against.