How to hire a developer without getting burned

Most bad hires begin with a vague message. If you cannot say who will use the software and what those people do all day, nobody can quote honestly. A loose brief invites a loose price.

Write one page. Name the users, the three main tasks, the files the software must read and what finished looks like. A photographed whiteboard sketch is enough.

Give every candidate the identical page, whether they came from Upwork, Fiverr, Toptal or a friend’s referral. Within a day you will see who reads closely. The rest paste a template reply.

Portfolios show polish, not judgment. A short paid task shows how someone thinks. Take a slice of your real job, such as a login page with one filtered report, and fix the number of days in writing.

Watch the questions. Do they check awkward cases like a blank field or a duplicate phone number? Do they flag doubts on day one? Good developers raise problems early, and they send a short screencast of what they built instead of a vague promise that it is nearly ready.

Pay for the trial. It is fair. It filters out people hunting for free ideas, and it hands you real code to inspect, which a friend can run a linter over in an afternoon.

Create the repository under your own Bitbucket or GitHub account and invite the developer in. Do the same for hosting on Heroku, DigitalOcean or Vercel, for the domain registrar, the payment gateway and the app store listing. Never let anyone register these under a personal email.

This costs nothing. It removes the worst risk. A builder who vanishes, or asks for more money before returning your property, can no longer hurt you much.

Ask for commits to the shared repository every working day. Code that lives only on a private laptop is a loan you never agreed to. Keep passwords in a shared vault with a keychain app on each phone, and never paste them into a Telegram chat.

Split the fee into milestones. Each should be something you can click through on a test link, such as a working login, a saved invoice PDF or a downloadable CSV. Pay when it works. Not when it is nearly there.

Hold back the last instalment until handover is complete. That means the source code, a setup guide, the account list and one recorded walkthrough call that a stranger could follow a year from now.

Never pay the whole amount in advance. A sound developer understands why. Anyone who argues hard has shown you who they are. Read every clause on withholding payment, arbitration and a nondisclosure promise before you sign, and strike any that bind only you.

Some signs appear early. A quote lands within an hour of a vague message. Answers change each time you repeat a question. A discount expires tonight. Praise sits on testimonial pages that you cannot trace to a real company.

Listen to how they speak about tests and backups. If both sound optional, your first outage will hurt. Ask what happens if they are unreachable for two weeks, then note the pause before they answer.

Before signing, send the trial result to a technical friend for a short review. One hour is cheap insurance. If a project still goes wrong later, write a plain postmortem so the next hire starts with the lessons rather than repeating them.