Most freelance developers are honest, skilled professionals, and hiring one is often an excellent way to get good work at a fair price. But the freelance market has no gatekeepers, and business owners without a technical background can find it hard to tell an expert from someone who sounds like one. Stories of abandoned projects, unusable code and disappearing developers are common enough to deserve a straightforward checklist. This article lists the warning signs we see most often, and how to protect yourself. It is deliberately about patterns, not individuals: any of these signs can occasionally have an innocent explanation, so investigate before you conclude.
Red flags in the proposal and price
- A price far below every other quote. A very low bid usually means the developer has not understood the scope, will cut corners on testing and security, or plans to recover the difference through change requests. Ask them to explain exactly what is included. See how we estimate projects for what a credible estimate looks like.
- A vague or absent proposal. No breakdown, no assumptions, no milestones and no description of what is out of scope.
- A confident single number after a five-minute conversation. Serious estimates come from questions about your users, data and integrations; see our discovery phase article.
- Requests for full payment upfront, or large deposits without deliverables. Payments should follow milestones.
- Pressure to sign immediately with "limited-time" pricing or "I have other clients waiting."
- Unrealistic promises: a complex platform in a few days, "guaranteed" search rankings or revenue, or "no bugs."
Red flags in communication
- Slow, evasive or sloppy responses before you have hired them. The sales period is when people are on their best behaviour.
- Not asking questions about your business. A developer who does not care why you need the software is unlikely to build the right thing.
- Jargon used to avoid clarity. Good professionals explain technical decisions in plain language.
- Reluctance to show progress. Long silences and "almost done" with nothing to see are typical of problems ahead; see how we keep clients in the loop.
- Blaming everyone else, from previous clients to previous developers, in every story they tell.
- Refusing calls or video, or persistent unreachability without explanation.
Red flags in evidence and reputation
- A portfolio with no live examples, only screenshots, or sites that they cannot explain their role in. Copied or purchased templates presented as custom work are a common tactic.
- No references, or references who cannot be contacted. Always speak to at least two recent clients.
- Suspicious reviews: many five-star reviews with generic text, all posted at once, or a profile created recently with an impressive claimed history.
- Inconsistent identity or story: different names, locations or work histories across profiles.
Red flags in ownership and access
- They want to register your domain, hosting or third-party accounts in their own name. You must own these; see what to look for when hiring and our DNS article.
- The code lives only on their machine, not in a repository you can access.
- Unclear intellectual property terms, or a contract that keeps the code owned by the developer until some future condition.
- Refusal to hand over credentials and documentation at the end without extra payment.
- Proprietary lock-in: tools or frameworks only they can maintain.
Protect yourself by keeping ownership terms in writing; see our note on protecting intellectual property.
Red flags in technical practice
- No mention of testing, version control or deployment process. Ask how changes are tested and released; see our CI/CD article.
- Casual attitude to security: shared passwords, secrets in code, no backups, no plan for updates; see our secrets guide, security audit guide, backups.
- Exotic or unnecessary technology choices that only they understand, or a stack chosen for novelty rather than fit.
- Heavy reliance on copying generated or pre-made code without understanding it. AI tools are legitimate when reviewed and tested, but a developer who cannot explain their own code is a risk; see our article on AI assistants.
- No plan for after launch: nothing about monitoring, support or maintenance; see our retainer article.
Red flags in contracts and business practice
- No written contract, or a contract with no scope, milestones or termination terms.
- Payment only by untraceable methods, or a request to move the conversation off the platform to avoid protections.
- A refusal to sign a confidentiality agreement.
- Unwillingness to describe what happens if the developer becomes unavailable.
The single-person risk
Even an excellent freelancer is a single point of failure: illness, a new job or a personal emergency can stop a project. Mitigate by insisting on documentation, code in your own repository, a second person who can read the code, and a short handover plan. For business-critical systems, consider an agency or a small team, or have an independent expert review the work periodically; see our article on long-term technical partnerships.
How to hire safely
- Write a clear brief so you can compare candidates on equal terms.
- Verify identity, portfolio and references. Open their live work on your phone; check speed and quality.
- Run a small paid trial on a real, self-contained task with a defined outcome and deadline. You learn about quality, communication and reliability cheaply.
- Use staged payments tied to delivered milestones, with a final portion on acceptance. Use platforms with escrow when appropriate.
- Get everything in writing, including ownership of code, accounts and data, confidentiality and termination. Consider legal review for larger contracts.
- Keep control of the assets: repository, hosting, domain and analytics registered to you from day one.
- Insist on regular demos and access to the staging site.
- Consider a technical review by an independent adviser for important projects.
If things are already going wrong
Secure your assets first: change passwords, transfer domains and accounts, and obtain a copy of the code. Document what has been delivered and paid. Ask for a code and infrastructure audit from a neutral party to assess whether the work is salvageable or needs to be rebuilt; we describe a typical audit in our legacy modernisation case study. Decide based on evidence, not sunk cost.
Not every project needs an agency, and many freelancers are wonderful. But if you want a team, documented process, references and shared ownership without the gamble, talk to us. Our software team offers a paid discovery phase so you can judge us on real work before committing; start a conversation. Our support team can also help rescue and stabilise projects that have gone off track.
Put this into practice with CodeLuma
If you would rather not gamble on a lone freelancer, CodeLuma offers a transparent team with references, documented process, and full ownership of code and accounts for you from day one.
- Custom software development - tailored systems, integrations and internal tools.
- Website and web application development - fast, accessible, search-friendly builds.
- CodeLuma support - help from a real team when you need it.
- Maintenance and support plans - updates, monitoring and ongoing improvement.
Start a conversation. Tell us about your project and we will reply with practical next steps, or browse all CodeLuma services. CodeLuma Development Inc. is based in Nova Scotia and works with teams across Canada and remotely.
