Hiring a freelance developer is often the right call for an SME. You get senior skills without a salary commitment, and for a scoped project the economics beat both agencies and full-time hires. But the failure stories follow a script I have heard dozens of times: the project starts warmly, drifts, then one day the developer stops replying and the business discovers it does not actually control its own website, code, or data.

Almost every one of those disasters announced itself early. There are freelance developer red flags that show up in the first conversations and first weeks, long before real money is lost. The trick is knowing what they look like, and pairing each one with a protective habit so you are covered even when a flag turns out to be a false alarm.

I have written before about choosing developers; this piece is about the working relationship itself, where most of the damage actually happens. Here are the seven flags I take most seriously, roughly in the order you will encounter them.

1. A Quote With No Questions

You describe your project in two paragraphs and get back a confident price and timeline. That should worry you, not impress you. Any competent developer knows your two paragraphs hide twenty decisions: payment gateways, user roles, admin features, hosting, data migration. A quote without questions means either the developer plans to build their assumptions instead of your needs, or the number is a hook that change requests will inflate later.

Protective habit: write a one-page brief and judge candidates partly on the quality of the questions it provokes. The developer who pushes back on your scope before quoting is the one taking your money seriously. A structured brief helps here; I laid out the format in How to Write a Software Brief Developers Won't Misread.

2. Everything Is "Sudah Hampir Selesai"

Weeks pass and every status update is a variation of "almost done," with nothing you can actually see. Software progress that cannot be demonstrated usually does not exist. Honest projects show ugly, partial, clickable progress early; troubled ones show nothing until a big reveal that keeps sliding.

Protective habit: structure the project around demos, not reports. Every one or two weeks, a working (if rough) version on a test URL you can open yourself. If a milestone cannot be demonstrated, it is not complete. Put this in the agreement before work starts.

3. The Code Lives Only on Their Laptop

Ask "can I get access to the source code repository?" and listen carefully. Hesitation, excuses, or "I'll hand everything over at the end" is one of the most dangerous flags on this list. If the developer disappears, burns out, or has a dispute with you, the code on their laptop disappears with them. I have watched a business pay twice for the same system because version one was unrecoverable.

Protective habit: a repository under an account your business owns (GitHub and GitLab are free), created in week one, with the developer pushing code to it continuously. This costs the developer nothing if their intentions are good, which is exactly why refusal tells you so much.

4. Hosting, Domain, and Services in Their Name

The site works, but the domain was registered under the developer's personal email, the hosting is on their account, and the payment gateway was set up with their details "to make things faster." Congratulations: your business is now a tenant in someone else's house. Renewal time, dispute time, or handover time is when you find out what that costs. Domain ransom situations are ugly, real, and mostly legal.

Protective habit: every account is created under your business email from day one: domain, hosting, payment gateway, email service, app store accounts. The developer gets invited as a collaborator with the access they need. Fifteen minutes of setup discipline eliminates the entire hostage category.

5. Full Payment Up Front, or Suspiciously Back-Loaded Enthusiasm

Payment structure is risk structure. A developer demanding 100 percent up front holds all the leverage; you hold hope. The reverse extreme, agreeing to full payment only at the end, sounds safe for you but often signals a developer desperate enough to accept terms that professionals decline, and desperation correlates with abandonment.

Protective habit: staged payments tied to demonstrated milestones. A common healthy shape for an SME project: 30 percent to start, 30 percent at the mid-project demo, 30 percent at delivery on your infrastructure, 10 percent after a two-to-four-week warranty period in production. Both sides carry some risk at every stage, which is the point.

6. Communication That Degrades Under Pressure

Early replies came in an hour; now questions sit unread for four days, and the answers that do come are defensive. Communication decay is usually the first visible symptom of deeper trouble: the developer is overcommitted, stuck on a problem they will not admit, or already prioritizing a newer client. The pattern rarely reverses on its own.

Protective habit: agree on a communication rhythm up front, something as light as a fixed weekly check-in call plus a 24-hour reply expectation on working days. Then treat the second missed check-in as a formal issue to raise directly, not an annoyance to tolerate. Naming the pattern early sometimes fixes it; waiting never does.

7. No Documentation, No Handover Plan

Ask "if you got hit by a bus, could another developer take over?" A professional answers with specifics: the code is in your repo, credentials are in a shared vault, there is a README explaining setup. A risky freelancer laughs it off, because being irreplaceable is, consciously or not, part of their retention strategy. Undocumented systems turn every future change into a renegotiation with the only person on earth who understands your software.

Protective habit: make documentation a paid deliverable in the scope: setup instructions, an environment and accounts list, and a short architecture note. Then verify it the honest way, by having someone else (even a technical friend) follow the setup guide before the final payment. Documentation you have not tested is documentation you do not have. The broader case for this is in Documentation Is the Cheapest Insurance You Can Buy.

Seeing One Flag vs. Seeing Three

One flag is a conversation. A good freelancer who has simply never worked with structured clients will adapt happily to your repo, your accounts, and your milestone demos, and many of the best independent developers I know actively prefer clients who work this way, because clear structure protects them too.

Three or more flags is a pattern, and patterns do not negotiate away. At that point the cheapest moment to exit is now, before more money and more entanglement accumulate. The sunk cost will whisper otherwise. Ignore it.

The Practical Takeaway

You do not need to become technical to be protected. You need five habits, all of which cost almost nothing: a written brief that provokes questions, a repository and all accounts under your own name from day one, payments staged against demos you can click, a fixed communication rhythm you actually enforce, and documentation as a tested deliverable. Put those in place and most red flags either never appear or cannot hurt you when they do.

The goal is not distrust. It is a structure where trust is never the only thing standing between your business and losing its own software.