Hiring the wrong developer doesn't just waste money—it wastes months of your time and leaves you with software that doesn't work. Here are the red flags we've seen sink projects, and how to spot them before you commit.
During the Sales Process
🚩 They don't ask questions
A developer who jumps straight to solutions without understanding your problem is either overconfident or doesn't care. Good developers are curious. They should be asking:
- What's the actual problem you're solving?
- Who will use this?
- What have you tried before?
- What does success look like?
If they're ready to quote without discovery, expect misaligned expectations later.
🚩 The price is suspiciously low
Custom software has real costs. If someone quotes significantly below market rate, something's off:
- They're outsourcing to inexperienced juniors
- They'll cut corners on quality
- The scope will "grow" once you're committed
- They don't understand what you're asking for
Cheap usually means expensive in the long run.
🚩 They won't give a fixed price
"We work hourly" isn't inherently bad, but beware of:
- Refusing to estimate at all
- "We'll figure out scope as we go"
- No caps or budgets discussed
- Vague timelines with no milestones
You deserve to know what you're paying for before you pay for it.
🚩 They promise everything
"Yes, we can do that. And that. And that too!"
Real experts know their limits. If a small team claims expertise in mobile apps, web apps, AI, blockchain, IoT, and enterprise systems—they're either lying or mediocre at everything.
🚩 No portfolio or references
Everyone starts somewhere, but for your money, you want proof they can deliver:
- Actual projects they've completed
- Clients you can talk to
- Code samples or demos
"We've done lots of projects but can't share them due to NDAs" for everything is suspicious.
During the Project
🚩 Communication goes dark
Early warning sign: response times stretch from hours to days. Updates become vague. Questions go unanswered.
Good developers communicate proactively, especially when things go wrong. Silence usually means problems they're not telling you about.
🚩 You never see working software
Weeks pass. You see designs, wireframes, "architecture documents"—but no actual working software.
Modern development should show progress quickly. If you're a month in without something you can click through, something's wrong.
🚩 "It's almost done" (repeatedly)
The project was supposed to take 8 weeks. At week 8: "Just a few more things to polish." Week 10: "Almost there." Week 12: "One more week."
This pattern rarely ends well. Either scope wasn't understood, estimates were fantasy, or the team is in over their heads.
🚩 Excuses blame everyone else
- "Your requirements changed" (when they didn't)
- "The third-party API is broken" (for weeks)
- "We're waiting on you" (for things you already provided)
Professionals own problems and solve them. Amateurs deflect.
🚩 They resist showing their work
You ask for access to the code repository: declined. You want to see the server setup: "It's complicated." You request documentation: crickets.
Your software is your property. You should have full visibility into what you're paying for.
Technical Red Flags
🚩 No version control
If they're not using Git (or similar), run. This is basic professional practice. Without it:
- Changes can't be tracked or reversed
- Collaboration is chaos
- There's no backup if something breaks
🚩 No testing
"We test manually before each release" might sound okay, but automated testing catches bugs faster and prevents regressions. Projects without tests become fragile—every change risks breaking something else.
🚩 No documentation
Code without documentation is a liability. When the original developer leaves, can someone else understand what they built? If not, you're dependent on one person forever.
🚩 It only works on their machine
"Works fine in our environment" is not acceptable. Software should be deployable, reproducible, and maintainable by someone other than the original builder.
Contractual Red Flags
🚩 You don't own the code
Read the contract. Some developers retain ownership and "license" the software to you. This means:
- You can't hire someone else to modify it
- They can use your code for other clients
- You're locked in forever
You should own what you pay for—fully, outright, no strings.
🚩 No defined scope or change process
If there's no written scope, there's no way to hold anyone accountable. And if there's no change process, scope will creep endlessly while you keep paying.
🚩 Payment terms that favor them
100% upfront is a red flag. So is "payment due regardless of completion." Standard terms:
- Milestone-based payments
- Final payment on delivery/acceptance
- Clear criteria for "done"
What to Do Instead
Check references (really)
Don't just ask for references—call them. Ask:
- Did the project finish on time and budget?
- How was communication?
- Would you hire them again?
Start small
If possible, do a small paid pilot before committing to a large project. See how they work, communicate, and deliver.
Get everything in writing
Scope, timeline, price, ownership, milestones, change process. If it's not written down, it doesn't exist.
Trust your gut
If something feels off during sales, it'll be worse during the project. The best predictor of future behavior is past behavior—and the sales process IS behavior.
Looking for a Team Without These Red Flags?
We're not perfect, but we're honest. Fixed prices, clear scope, you own everything, and we'll tell you if we're not the right fit.
Part of our series on hiring developers wisely. See also: Questions to Ask Before Hiring and How to Write a Project Brief.