The warning signs that a developer, freelancer, or agency will waste your time and money — and what to look for instead. Based on patterns we've seen across dozens of rescue projects.
Red flags when hiring a developer: Warning signs include no discovery process (they quote without understanding your requirements), no portfolio of similar work, vague estimates ("it depends"), reluctance to provide a fixed price, no mention of testing or deployment, poor communication during the sales process, and unwillingness to sign a contract with clear deliverables. If they can't be professional before you pay them, they won't be after.
We've rescued projects from failed freelancer engagements, abandoned agency partnerships, and developers who simply disappeared. After seeing the same patterns repeat, we've compiled the warning signs that reliably predict a bad outcome.
This isn't about being paranoid. It's about knowing what to watch for so you can walk away early — before you've invested months and lakhs into the wrong partnership.
For a complementary view on what questions to ask, read our questions to ask a development team guide. For a broader evaluation framework, see how to evaluate a software development agency.
"Yes, we can do that. Yes, that timeline works. Yes, that budget is fine."
No pushback. No questions about priority. No "have you considered...?" When a development partner agrees with every request without qualification, it means one of three things:
What good looks like: "We can build what you've described, but for your budget and timeline, I'd suggest cutting [X] from v1 and adding it in the second sprint."
"Send us the requirements and we'll get started."
If they can't articulate a step-by-step process for how they work — discovery, specification, design, development, testing, deployment — they're winging it. And winging it works until it doesn't.
What good looks like: A documented process they can walk you through in 5 minutes, with clear phases, deliverables, and your involvement defined.
"We need to do a detailed analysis before we can quote."
A 6-week detailed analysis? No. An experienced team can give you a rough range after a 30-minute conversation. "Projects like this typically cost ₹8L–₹15L depending on scope." That's not a commitment — it's a signal of experience.
If they refuse to discuss pricing at all before you've signed an NDA and gone through multiple meetings, they're either inexperienced or hiding high prices behind process.
What good looks like: "Based on what you've described, we're looking at ₹X–₹Y. Here's what would push it toward the higher end."
They claim to build complex web applications, but every portfolio item is a WordPress site or a landing page. They claim e-commerce expertise, but there are no live stores to click through.
Always verify the portfolio:
Legitimate companies don't require full payment before work begins. Standard terms are 50/50 (upfront/delivery) or milestone-based.
100% upfront means you have zero leverage if things go wrong. Walk away.
"We'll host the repository and give you access when the project is done."
This is a control mechanism, not a practical necessity. Your code should live on your GitHub/GitLab account from day one. If they refuse, they're prioritizing their leverage over your ownership.
If a company requires you to sign an NDA before a basic discovery call, they're either overly bureaucratic or trying to create a sense of obligation before you've decided anything.
NDAs make sense for specific, proprietary technical details. They don't make sense for "tell me about your idea at a high level."
"We'll show you the progress at the next milestone."
If you can't see the product being built in real-time on a staging URL, you have no idea what's actually happening. A team that doesn't deploy to staging regularly is either disorganized, behind schedule, or building something they don't want you to see yet.
What good looks like: A staging URL from week one. Updated daily or every few days. You can visit and test anytime.
Week 3: "Almost done, just finishing up." Week 5: "Almost done, one more thing." Week 8: "Almost done..."
Software development estimates are hard, and delays happen. But "almost done" repeated without specifics about what remains is a sign that the developer has lost track of the scope or is avoiding a difficult conversation about timeline.
What good looks like: "We have 3 tasks remaining: payment integration (2 days), email notifications (1 day), and final testing (1 day). We'll be done by Thursday."
During the sales process, responses were within hours. Now you wait 2 days for a reply. Meetings get rescheduled. Updates stop coming unless you ask for them.
Communication quality should stay consistent or improve once work begins. If it degrades, the team has either over-committed, de-prioritized your project, or is struggling with the work.
You were told you'd work with a senior developer. Suddenly your questions are being answered by someone you've never heard of, using different patterns and making different decisions.
Staff rotation isn't inherently bad — but it should be communicated. If new people appear silently, the team is either stretched thin or the person you were promised isn't actually working on your project.
"Why does the loading take 4 seconds?" "That's normal."
"Can you explain this architectural decision?" "It's too technical to explain."
"This doesn't match what we discussed." "Well, this is how it has to be done."
A good team welcomes questions and explains their reasoning. Defensiveness signals either insecurity, incompetence, or a team that's cutting corners and doesn't want scrutiny.
The project was supposed to include features A, B, C. Now they're building A, B, C, D, E, F — and the timeline hasn't changed. This means they're either billing you more later, cutting quality, or have lost control of scope.
What good looks like: "We noticed the checkout flow is more complex than spec'd. Here's the additional scope, here's what it costs, and here's the timeline impact. Want to include it or save for v2?"
Ask: "Where's the code?" If the answer isn't a Git repository (GitHub, GitLab, Bitbucket), that's a fundamental problem. Code should be version-controlled, backed up, and accessible.
If they're emailing you ZIP files of code, run.
You receive the code with no README, no setup instructions, no architecture overview, no API documentation. If another developer needs to work on this codebase, they're starting from zero.
Bugs found after launch are "new development" that requires additional payment. A reputable team includes at least 30 days of post-launch bug fixes as part of the project cost.
The admin panel only they can access. The deployment process only they know. The database only they have credentials for. If you can't operate your own product without their involvement, you're locked in.
For contrast, here's what a healthy engagement feels like:
Trust your instincts. If something feels off, it usually is.
If you're seeing these signs on a project that's already in trouble, read our guide on signs it's time to switch your software agency and how to evaluate a replacement agency.
We've taken over dozens of projects where the previous team went quiet, delivered unusable code, or left mid-build. Our first step is always a code audit — an honest, written assessment of what exists, what's salvageable, and what the path forward looks like. No commitment beyond that until you've seen the report.
→ Project Takeover Service · → Request a Code Audit
Call +91 90358 61690 · Book a free call · Contact form
If this guide resonated with your situation, let's talk. We offer a free 30-minute discovery call — no pitch, just honest advice on your specific project.
A practical guide for non-technical founders on how to split equity with a technical co-founder — what factors should drive the number, what vesting protects you both, and how to have the conversation before it becomes a crisis.
11 min readChoosing a PartnerAn honest comparison of fixed-price and hourly billing for software development — when each model makes sense, the hidden risks of both, and how to structure an engagement that protects you.
10 min read