15 Red Flags When Hiring a Developer (and What Each One Costs You)

The most serious red flags when hiring a developer have little to do with programming languages. They're about agreements and ownership: no written contract, code that lives on the developer's own account, no tests, and a price that doesn't tell you what's excluded. Below are 15 warning signs, what each one tends to cost you, and what to ask for instead.

I am a freelance developer based in Denmark, so I have a stake in this topic. This breakdown shows the work behind the price.

The short answer: all 15 at a glance

My rule of thumb: one of the five "yes" items that isn't fixed before work starts is enough to move on. A single item from the rest can have a good explanation, so ask. If you spot three or more with the same developer, pick someone else, even if each answer sounds reasonable on its own.

This list is for when you've spoken to a few candidates. If you haven't, start with my step-by-step guide to hiring a developer. If you want to probe these points on a call, I've put together 27 questions to ask a developer before you hire them.

First contact: warning signs before you get a quote

1. Slow or vague replies before you've signed

Before the contract is signed, you're the client the developer is trying to win. If a week passes between replies already, or the emails don't answer what you asked, you've seen a preview of the project.

What it can cost: Waiting at every step. A question that takes five days to answer can block the work for five days.

Ask for this instead: A specific response time and an agreed channel for urgent issues. My own commitment is a reply within one business day. You don't need that exact number, but you need a number. If the developer is in another time zone, also agree on which hours overlap.

2. The developer asks no questions and agrees to everything

On a first call, a good developer wants to know who the users are, how the work gets done today and what has to be ready at launch. If every idea gets a yes and nothing gets a follow-up question, the job hasn't been understood yet.

What it can cost: A product that solves the problem the developer imagined, not yours. And someone who never disagrees with you during the sales stage is unlikely to start when the money is running low.

Ask for this instead: A suggestion for what could wait until version two. It shows the developer is thinking about your budget.

3. You can't meet the person who writes the code

You talk to a salesperson or a project manager, and when you ask who will do the programming, the answer is "the team". Sometimes the work has been passed on to a subcontractor without anyone telling you. Subcontractors aren't a problem in themselves, but hidden ones are.

What it can cost: Every message goes through an extra layer, and details get lost on the way. Your data and code end up with people you have no agreement with, which is a GDPR issue if personal data is involved.

Ask for this instead: The name of whoever writes the code, and a short call with them before you sign. If subcontractors are used, the contract should say so.

4. There's nothing you can see or check

The portfolio is polished screenshots, every project is "under NDA", and there are no past clients you can call. NDAs are real on some projects, but rarely on all of them.

What it can cost: You only find out their real level after paying for the first few months.

Ask for this instead: A project you can try yourself, an honest description of the developer's own role, and two past clients you're allowed to contact. What to ask them is covered in my reference check questions for developers.

5. You're pushed to decide fast

The discount ends on Friday, or there's "another client who wants the slot". Good developers are often busy, but they don't rush you.

What it can cost: Pressure works because it makes you drop references, the contract review and the comparison with other quotes. Those are exactly the checks that catch the rest of this list.

Ask for this instead: Time to read the contract and speak to references. If the developer genuinely only has availability from a certain date, they can say so without turning it into an ultimatum.

Price and quotes: when the numbers don't add up

6. A fixed price after a ten-minute call

You described the project loosely on a short call, and the next day a fixed price arrives without a single follow-up question. Fixed pricing works well for a clearly defined job, but nobody can price a project they don't understand.

What it can cost: Either there's a large buffer built in, so you pay for the uncertainty. Or anything that wasn't in your short description becomes a change request with its own invoice.

Ask for this instead: A range and an explanation of where the uncertainty sits. On larger projects, a short paid discovery phase is the most reliable route to a fixed price you can actually budget for. That's how I start larger projects myself, so weigh the advice accordingly.

7. The price is vague, or "everything is included"

The quote is one lump sum with no line about what it covers. Ask about hosting, licenses or maintenance after launch, and the answer is that it's all in there.

What it can cost: The bills arrive later. Common examples are hosting, payment processing fees, transactional email, paid APIs, copy and images, and ongoing security updates.

Ask for this instead: A list of what the price doesn't cover, and a rough estimate of the monthly running costs.

8. The price is far below every other quote

If two quotes land around €20,000 and the third says €5,000, there's a reason. Sometimes it's a good one: the developer has built something similar and can reuse a lot. More often something has been cut without being mentioned.

What it can cost: It's usually tests, security, documentation or time spent understanding your business that disappears. You won't notice at launch. You'll notice when the first changes are needed, or when another developer has to take over.

Ask for this instead: An explanation of the difference, item by item. Ask every bidder to describe the same things: screens and functionality, integrations, testing and what happens after launch. Then the gap becomes visible.

9. The developer wants the full amount upfront

A deposit at the start is normal. The full amount before a line of code is written is something else.

What it can cost: You have no leverage if the quality disappoints, the timeline slips or the developer disappears. Recovering money is slow and expensive, especially across a border.

Ask for this instead: Payment tied to milestones you can see and test, or monthly invoicing with a breakdown of hours and tasks. This is one of the five points where I'd walk away if it doesn't change.

Contracts and ownership: the warning signs that cost the most

10. There's no written contract

The agreement is a quote in an email and a "we'll figure it out". The problems start when you disagree about what was included, what a change costs, or what happens if you part ways.

What it can cost: Beyond scope disputes, there's copyright. Under the EU Software Directive, the economic rights in a program written by an employee as part of their job go to the employer automatically unless a contract says otherwise. A freelancer isn't an employee. Without an agreement that assigns the rights to you, it's not a given that the code is yours, even though you paid for it. National rules vary, so on a larger project an hour with a lawyer is money well spent.

Ask for this instead: A contract that covers scope, changes, payment, rights, access and termination, plus which country's law applies if you're in different countries. Changes should be priced and approved in writing before anyone works on them. I've listed what a freelance developer contract should include.

11. The code lives on the developer's own account

The code sits in a repository on the developer's GitHub or GitLab account, and you'll get it "when the project is done" or "once everything is paid". That sounds harmless until you disagree.

What it can cost: The developer is holding your code as collateral. If you want to switch, you depend on the person you're trying to leave. If they disappear, you may not have the latest version. If you're already in that spot, read how to switch developers mid-project without losing your work.

Ask for this instead: A repository created under your company's own account from day one, with the developer added as a member. It takes a few minutes to set up. That's how I work: the code belongs to the client from the start.

12. Domain, hosting and accounts are in the developer's name

The same goes for everything around the code: the domain, the server, the payment provider, the email service and the API keys the system relies on. If they're registered to the developer and paid with the developer's card, it's effectively the developer's system.

What it can cost: A dispute or a missed renewal can take your site down, and moving a domain registered to someone else is slow and awkward. Even when things are going well, you need permission to give anyone else access.

Ask for this instead: Every account set up in your company's name with a shared company email as owner, and user access for the developer. A complete list of accounts and access should be part of the handover.

How it gets built: problems you notice later

13. No tests and no staging environment

Ask how the developer makes sure things work, and the answer is "I test it myself". There are no automated tests and no staging environment (a private copy for testing), so changes go straight to your users. For a small brochure site, that can be fine. For a system your business depends on, it isn't.

What it can cost: Every new feature can break something that used to work, like login or checkout, and a customer is the one who finds out. Over time each change takes longer, because nobody dares touch the code.

Ask for this instead: Automated tests for the parts that must never break, and a staging environment where you can try changes before they go live. I've covered what else to look for in signs of a healthy codebase.

14. You see nothing until handover

The plan is that you'll see the whole system when it's finished in four months. Until then, you get status emails saying it's going well.

What it can cost: Misunderstandings surface at the point where they're most expensive to fix. A button in the wrong place is easy to move. A wrong assumption about how your orders are processed can mean large parts need rebuilding.

Ask for this instead: Access to staging within the first few weeks, and a short demo every week or two where you see something working, not just a slide deck.

15. The system is built on something only they understand

The developer has their own framework, their own CMS or a niche technology that few others use. It might be well made, but it ties you to one person.

What it can cost: When the developer is ill, overbooked or moves on, nobody else can step in without spending a long time getting up to speed. In the worst case, the system has to be rebuilt.

Ask for this instead: A reason that's about your project, not the developer's habits. Widely used frameworks like Laravel, React and Next.js make it far easier to find another developer later. They're also what I work with, so I'm not entirely neutral here.

Warning signs that are often good signs

Some things look like red flags but usually point the other way:

• The developer advises against a feature or suggests it waits. That saves you money.
• A paid discovery phase comes before the fixed price. That's the cost of an estimate that holds, and it's how I work myself.
• There's a modest deposit at the start. That's normal. Full payment upfront is the problem.
• The developer says "I don't know, I'll get back to you". That beats a confident guess.
• The developer isn't the cheapest. Price alone says little about quality, in either direction.
• The developer is open about using AI tools. Hidden use without human review is what should worry you.

What to do when you spot a red flag

A red flag doesn't have to end the conversation. Here's how I'd handle it:

1. Ask directly. Say what you noticed and why it concerns you. A good developer won't be offended.
2. Get the fix in writing. A verbal "sure, we can do that" isn't enough when it comes to ownership, access and payment.
3. Watch the reaction. If the developer gets defensive, or explains at length without changing anything, that's an answer in itself.
4. Move on if one of the five critical points isn't fixed. Two extra weeks finding someone else costs less than switching developers halfway through a project.

Next steps: run the list before you sign

Go through the list for each candidate right after your last call. Tick off what you saw and write the developer's explanation next to it. Then you're comparing facts, not gut feelings.

The list might also tell you not to hire a freelancer like me. If you need a developer embedded in your team for years, hiring one is usually cheaper and more stable. If you need design, copy and development as one package, an agency is often the better fit. To see what kind of work I take on and how I handle contracts, code and access, have a look at my services as an EU-based freelance developer.

Frequently asked questions

What should I do if I spot a red flag after the project has started?+

Fix ownership first. Ask for the code to be moved to a repository on your own account, and have the domain, hosting and other accounts transferred to your company's name. Then put a written agreement in place for the rest of the project. This is far easier while the relationship still works, so don't wait for a dispute.

Do the same red flags apply to agencies?+

Yes, almost all of them. With agencies, it's especially worth checking who actually writes the code and whether the solution is built on the agency's own CMS or platform that nobody else can work with. Full payment upfront is less common, but still ask about the payment schedule and who owns the code.

How big a deposit is reasonable?+

There's no fixed standard, but my rule of thumb is that a deposit should cover no more than the first piece of work you can see the result of, such as the first milestone or a discovery phase. The rest should be paid as you receive things you can test. That spreads the risk fairly evenly between you and the developer.

Is it a red flag if a developer won't sign an NDA?+

Not necessarily. Many developers are wary of broad NDAs before they even know the project, because they can restrict other work. A short, mutual agreement is reasonable when you're sharing trade secrets or customer data. If the developer refuses that too, it's worth asking why.