Most founder-developer relationships that go wrong were avoidable from the first call. The warning signs are usually there; founders either didn't know to look for them or didn't want to believe what they saw. I've been on both sides of this — I've been hired after a bad predecessor (four times this year alone), and I've walked away from calls where I was the one being assessed.
Here are the red flags I'd want my non-technical friend to know about before signing anything.
Red flags on the first call
1. They can't walk you through their stack choices
You ask, "Why Next.js over Remix?" or "Why Postgres over MongoDB for this?" and they say "it's what I know" or "it's what everyone uses."
Fine answers if you're hiring for implementation-only. Bad answers for someone who'll own architecture decisions that bind you for 2 years. A senior developer should be able to name one thing they dislike about their favorite tool, one situation where they'd pick a different one, and what would change their mind. If everything is "my stack is just right" — they haven't actually evaluated alternatives.
2. They agree with everything you say
You float a bad idea. "I think we should build a native app first." A good developer pushes back — "Let's talk about why, responsive web might get you to the same place for a third of the cost." A red-flag developer says "sounds great, we can do that."
A developer who agrees with every product decision is either not confident enough to contradict you, not experienced enough to have opinions, or is pricing in the future scope changes as revenue. All three are expensive for you.
3. They can't name a project they learned something painful from
"What's a project where you screwed something up?" is a load-bearing question. Answers to watch for:
- "I've never really had a project go wrong" — either lying or they've only done small work.
- "My clients have always been happy" — not an answer, also concerning.
- "One time I did X, we launched, it broke in production, I fixed it by Y, and now I always do Z" — that's the answer.
Scar tissue is what you're paying for. If they don't have any, they'll grow it on your project.
4. They insist on hourly for an obviously-scopeable project
"I only do hourly" for a tiny, well-defined project (a design system, a specific integration) is often fine. "I only do hourly" for an MVP with a clear brief is usually a signal that they don't want the commitment of a fixed quote — either because they're bad at estimation or because they're planning to pad. More on this in fixed vs hourly.
5. They dodge the "who else will touch this code?" question
You want to know: is this one dev, a team, or a revolving cast of contractors? If the answer is vague ("I'll have help if needed") — press. Founders who don't know who's in their repo end up with code that no one person can defend.
Red flags in their portfolio
6. Everything is a screenshot, nothing is a live URL
Screenshots are cheap. A screenshot of a polished dashboard proves they can use Figma. A live URL proves the product ships and runs.
Ask for live URLs. If they can't share any because "all my clients are under NDA" — one or two, sure. If every single project is NDA-locked, they either work exclusively on stealth startups (rare) or they're massaging what's actually deployed (common).
7. No numbers anywhere
Case studies full of adjectives ("beautiful," "fast," "delightful") and empty of numbers (load time, conversion delta, uptime, scale) are marketing, not proof. Every real project has measurable outcomes. If a dev's case studies don't have them, they either didn't measure or the numbers were bad.
8. The portfolio dates don't add up
Look at the project dates. If they claim 10 years of experience and every project is from the last 18 months, either the earlier work is hidden (why?) or they're inflating tenure. Not inherently disqualifying, but worth a direct question.
9. They list frameworks, not outcomes
"React, Node, TypeScript, AWS, Docker, GraphQL, Next.js, Tailwind, Prisma, PostgreSQL, Redis, Kubernetes..." is not a portfolio; it's a LinkedIn skill list. What did they build, for whom, with what outcome? If a portfolio answers only the "what tools" question and not "what problem," they're selling competency-as-commodity, not judgment.
Red flags in the quote
10. Fixed price with no scope document attached
"€30,000 to build your MVP" — with no written scope — is not a quote, it's an invoice for mutual disappointment. Any real fixed-price quote comes with a spec document describing what's in and what's out. If you ask for the spec and get "we'll figure it out as we go," you're paying for a thing nobody has defined.
11. The rate is absurdly low for the seniority claimed
A "senior full-stack developer in Europe/US" at €30/hour is either not senior or not doing the work themselves. Plenty of excellent developers in different markets work at different rates, but within a market, rates cluster. A dev dramatically below the market is either building up their portfolio (fine, be aware), subcontracting to someone else you're not meeting (concerning), or misrepresenting seniority (walk away).
12. No warranty, no handoff, no support window
A good engagement includes some period where bugs found after delivery are fixed without extra charge (30 days is typical, some do 60). No warranty at all means the developer's incentive on the last day is "ship, bill, exit" — which means launch-day bugs become your problem at extra cost.
Similarly: no handoff. If their plan is "here's the repo, good luck," and they haven't documented deployment, credentials, the weird thing in line 481, you're paying for a gift that will break.
13. Payment 100% up front or 100% at the end
Neither is normal for milestone-based work. Up front means the developer has no incentive to finish; end-of-project means you have no leverage if they ghost. Milestones (typical: 25/25/25/25 or 20/30/30/20) align incentives on both sides. A dev who insists on one of the two extremes is structuring the engagement in their favor, not in a balanced way.
Red flags in the contract
14. Vague IP/ownership terms
You're paying for the code. The contract should say — in plain language — that on full payment, all code, designs, and assets are yours, with broad enough rights to modify, sublicense, and distribute. If the contract says they're granting you a "license to use" or reserves "rights to reusable components," negotiate or walk. Founders have been burned when they later discover their "own" product uses a codebase the dev is licensing to competitors too.
15. Arbitration in a jurisdiction that isn't yours or theirs
"Disputes go to arbitration in the British Virgin Islands" on a contract between a founder in Germany and a dev in Poland is a flag. Not always malicious — sometimes they're using a boilerplate template — but ask. A contract that disincentivizes enforcement is a contract that doesn't protect you.
16. No termination clause
Every engagement should be terminable. For cause, without cause, with reasonable notice (2 weeks is common). If the only way to end the engagement is complete it, both sides are trapped if things go sideways.
Red flags in communication
17. Long silences
The single most predictive red flag for me. A dev who takes 4 days to respond to a "can we chat" email will take 4 days to respond to "production is down" and 4 days to respond to "we need to revise scope." Communication cadence during sales is the best they will ever be. It sets a ceiling, not a floor.
For my own work I commit to response within 1 business day. I don't always match that standard, but I measure against it. A dev who doesn't measure their own responsiveness will have worse responsiveness once they're locked in.
The green flags worth watching for
Since I've listed 17 ways to lose, three ways to win:
They ask hard questions back. "Why this feature first and not that one?" "What's your traction right now?" "What happens if we launch in 10 weeks but conversion is bad?" A developer who engages with your product rather than just your spec is thinking about whether to take your money responsibly.
They tell you what they won't do. "I don't do pure frontend gigs." "I don't work with agencies as a subcontractor." "I won't skip testing to hit a deadline." Limits suggest a real business, not someone chasing every dollar.
They recommend someone else if you're not a fit. This is the best signal. A dev who says "I'm not the right match for this, but I know someone who is — here's an intro" is confident enough in their pipeline that losing one deal doesn't matter, and honest enough to tell you the truth. I try to do this on every call where the fit isn't right. It's also how I've gotten a third of my own clients.
The gut check
If you're on the fourth call with a candidate and you still feel uncertain, trust that. Developers who are the right fit make it easy to say yes — not because they're salesy, but because the answers are clear, the portfolio speaks, the contract is fair, and the communication is responsive.
When you have to talk yourself into it, you're usually right to hesitate. Trust that.
If you want a 20-minute call where I'll give you an honest read on whether a developer you're considering is legit — no engagement, no sales — send me their site or proposal and I'll tell you what I see. Contact me. I'd rather spend 20 minutes helping you avoid a bad hire than watch you hire me to clean up after one.