The biggest red flags when hiring a software development agency are: no fixed scope or an open-ended hourly arrangement with no cap, refusing to let you own the code you paid for, no direct access to the engineers doing the work, suspiciously low bids that undercut everyone else, skipping any real discovery process, and vague timelines with no milestones. If you see several of these together, walk away. A trustworthy engagement is the opposite — a defined scope, code ownership written into the contract, direct engineer contact, transparent pricing, and a paid discovery phase before anyone writes production code.
Hiring a development partner is a high-trust decision made with low information. You're evaluating work you can't see yet, in a domain you may not fully speak, from people who are financially motivated to sound confident. This guide is written from the other side of the table — as senior engineers who have inherited plenty of half-finished, undocumented projects from the last vendor. Here are the warning signs, grouped by theme, and what "good" actually looks like.
Pricing and contract red flags
Money is where most engagements quietly go wrong. The problems rarely show up on day one — they show up three months in, when the invoice no longer matches the progress.
1. Open-ended hourly with no cap
Hourly billing isn't evil, but hourly billing with no ceiling and no fixed deliverable transfers all the risk to you. Every delay, every misunderstanding, every rewrite is billable. If the agency can't tell you what "done" looks like or what it costs, they're asking you to fund their learning curve.
What good looks like: a fixed scope for a defined deliverable, or hourly work with a hard cap and clear checkpoints where you can stop.
2. Suspiciously low bids
If one quote is a third of the others, that is information, not a bargain. Nobody builds the same thing for a third of the cost by being clever. They build it by cutting things you can't see yet — testing, security, documentation, error handling — or by planning to make it up in change requests once you're locked in. This is how the "cheap offshore dev" horror stories actually happen: the sticker price was real, but so was everything left out of it.
What good looks like: a quote in the same range as its peers, with a written breakdown of what's included and what's explicitly out of scope.
3. They won't let you own the code
This is the one that ends careers. Some agencies retain ownership of the code, host it on infrastructure only they control, or write the contract so you're licensing your own product back from them. The moment you want to leave — or they raise their rates — you have nothing.
What good looks like: the contract states you own all deliverables and IP outright, the code lives in a repository you control, and you can walk away with everything at any time.
4. Vague or padded timelines
"A few months" is not a timeline. Neither is a single delivery date six months out with nothing in between. Both hide the same thing: no real plan. You won't know you're in trouble until the deadline arrives and slips.
What good looks like: milestones every two to four weeks, each with something you can see and test, so problems surface early and cheaply.
Here is the pricing and contract picture at a glance:
| Red flag | Why it's risky | What good looks like |
|---|---|---|
| Open-ended hourly, no cap | You fund every delay and rewrite | Fixed scope or capped hours with checkpoints |
| Suspiciously low bid | Real costs get cut or clawed back via change orders | Quote in market range with written inclusions |
| No code ownership | You're locked in and can't leave | You own the IP and the repository outright |
| Vague timeline | You learn you're behind only at the deadline | Milestones every 2–4 weeks you can test |
| Large upfront deposit | Little recourse if work stalls | Payments tied to delivered milestones |
On that last row: deposits are normal, but front-loading most of the fee is not. Tie payments to things you can actually see.
Communication red flags
How an agency communicates during the sale is the clearest preview of how they'll communicate once they have your money — usually the best it will ever be.
5. You only ever talk to a salesperson
If a polished account manager fields every question and the engineers are kept behind glass, ask why. The person who can't answer a technical question shouldn't be the only person you're allowed to talk to. Details get lost in translation, and you can't judge whether the people writing your software actually understand the problem.
What good looks like: you talk directly to the engineer or technical lead who will do the work — before you sign, and throughout.
6. Jargon instead of answers
Watch for the move where a plain question gets a wall of buzzwords in return. Competent engineers can explain a trade-off in language you understand, because they actually understand it themselves. Jargon is often used to end a conversation, not to have one.
What good looks like: a straight answer, in plain terms, including the honest "it depends, and here's what it depends on."
7. Slow, vague, or evasive responses
If it takes a week to get a quote and answers arrive fuzzy, that's the pattern for the whole engagement. Responsiveness before the contract is a leading indicator.
What good looks like: timely, specific replies, and a named person accountable for the relationship.
8. The disappearing act
The classic freelancer failure — and it happens with agencies too. Work goes quiet, updates dry up, and you're chasing someone who's moved on to a bigger client. Solo developers are especially exposed here: if the one person gets sick, gets a better offer, or simply ghosts, your project stops dead with no one to pick it up.
What good looks like: more than one person who understands your codebase, work committed to your repository continuously, and documentation that means the project survives any single person leaving.
Technical and process red flags
The last group is the hardest to evaluate without technical help, which is exactly why weak agencies rely on you not looking.
9. No discovery process
Any agency that quotes a fixed price and timeline for a substantial build after one call is guessing — and you'll pay for the wrong thing when the guess is wrong. Real projects have unknowns that only surface when someone digs into your actual requirements, data, and constraints.
What good looks like: a paid discovery phase that produces a scope, an architecture, and an estimate you can trust — or take to another vendor. Paying for discovery feels like a leap of faith you'd rather skip, but it's the opposite: it's how you replace a leap of faith with a plan. We wrote more about scoping a first build in no-code vs. custom for your MVP.
10. No testing, review, or documentation
Ask how they test, how code gets reviewed, and what documentation you'll receive. If the answer is hand-wavy, you're buying a black box that only they can maintain — which is precisely the lock-in you're trying to avoid. Skipped tests and missing docs are invisible on delivery day and expensive on every day after.
What good looks like: automated tests, peer-reviewed code, and documentation handed over as a deliverable, not an afterthought.
11. No references or verifiable work
Everyone claims great results. Fewer can point to shipped work, a code sample, or a client who will take your call. You don't need a famous logo wall; you need evidence that real software got built and stayed built.
What good looks like: work you can inspect, references you can contact, and specifics instead of superlatives.
12. Overselling AI (or any trend)
In 2026, the fashionable red flag is an agency promising to solve everything with AI. AI is a genuinely powerful tool for the right problem, but "we'll add AI" as a headline pitch — with no discussion of your data, accuracy requirements, or whether a simpler approach would work — is salesmanship, not engineering.
What good looks like: honesty about when AI helps and when it doesn't, grounded in your actual use case rather than the trend of the quarter.
Turning the red flags into a checklist
Read the list backwards and you have your vetting questions. Before you sign, confirm you can answer yes to these:
- Is the scope defined, with a fixed price or a capped budget?
- Does the contract say I own the code and the IP?
- Can I talk directly to the engineer who'll build it?
- Are there milestones I can see and test every few weeks?
- Is there a real discovery phase before production work?
- Will I get tests, code review, and documentation?
- Can I verify their past work and reach a reference?
If a prospective partner clears all seven, the low-information problem you started with is mostly solved. You can see this same philosophy in how we structure custom software builds and MVP development, and across our services overview.
Frequently asked questions
How do I know if a developer is overcharging me?
Compare at least three quotes and look at the spread. If one is dramatically higher with no clear reason, ask what's included that the others omit — sometimes it's justified, sometimes it's padding. If one is dramatically lower, assume corners are being cut. The most reliable defense against overcharging isn't haggling; it's a fixed scope tied to defined deliverables, so you're paying for outcomes rather than open-ended hours.
Should I pay for a discovery phase?
For anything beyond a trivial project, yes. A paid discovery phase forces the hard questions — requirements, architecture, edge cases — to the surface before they become expensive surprises mid-build. The deliverable should be yours to keep: a scope and estimate you could hand to a different agency. If discovery is competent, you'll either move forward with confidence or dodge a bad fit cheaply. Either outcome is worth the fee.
Fixed price or hourly — which is safer?
Fixed price is safer when the scope is well understood, because it moves delivery risk to the agency. Hourly is more honest when genuine unknowns remain — but only with a cap and regular checkpoints where you can reassess or stop. The genuinely risky option is uncapped hourly with a vague deliverable, which is neither. A common healthy pattern is fixed-price discovery, then fixed-price or capped delivery once the unknowns are resolved.
What if the agency won't give me direct access to engineers?
Treat it as a serious warning sign. Salespeople and account managers have a role, but if the people writing your software are never allowed to speak to you, you can't assess their competence or catch misunderstandings early. Insist on at least one direct conversation with the technical lead before signing. How they respond to that request tells you most of what you need to know.
Working with us
We built Agapelo to be the counter to this list. We work fixed-scope, you own the code and IP outright, and you talk directly to the senior engineer building your product — not a layer of sales. If that's the kind of engagement you're looking for, get in touch and we'll start with an honest conversation about scope before anyone asks you for a commitment.