How to hire a freelance software engineer without getting burned

To hire a freelance software engineer without getting burned: verify they have shipped software that is still running today, talk directly to the person who will write the code, start with a small fixed-scope paid milestone, keep the code and every account in your name from day one, and treat weekly demos of working software as the only progress report that counts. Do those five things and a bad hire costs you a few thousand dollars and a month, instead of a year and a rewrite.

I am a freelance software engineer, so this article is me telling on my own industry. A meaningful share of my projects over the years have been rescues: systems started by someone else that arrived half-finished, undocumented, or built so only the original author could touch them. The patterns behind those rescues repeat, and every one of them was visible before the contract was signed.

Why does hiring engineers go wrong so often?

Information asymmetry. You cannot read code, so you cannot directly evaluate the thing you are buying, and confidence is cheap to fake in a sales call. The way out is to stop trying to evaluate the code and start evaluating behavior: what they have shipped, what they ask you, how they structure the deal, and how they handle being unavailable. Those are observable before you spend real money, and they predict the outcome better than any portfolio page.

What should you check before the first call?

Three things, none of which require technical knowledge:

• Software that is still in production. Not screenshots, not GitHub activity: real products, with users, that have been running for years. Ask “what have you built that is still running today, and who maintains it?” Longevity is the hardest credential to fake. I lean on this myself; a decade maintaining one client’s platform says more than any certification I could list.
• Maintenance history, not just launch history. Anyone can ship version one. The engineer you want has lived with their own decisions for years and can tell you which ones they regret. Ask what they would do differently on an old project; a thoughtful answer is a green flag, a blank stare is not.
• How they write. You will communicate with this person in writing for months. If their proposals, articles or even emails are specific and clear, the collaboration usually is too. Vague writing predicts vague software.

Which questions expose a weak engineer in ten minutes?

Steal these for the first call:

1. “What would you NOT build in this project?” Strong engineers cut scope on instinct and will happily tell you which of your ideas to postpone. Weak ones say yes to everything, because every yes bills.
2. “Walk me through something you shipped that is still running.” Listen for specifics: real constraints, real numbers, a trade-off they can defend. Buzzword tours mean the depth is not there.
3. “What happens when you are sick, on vacation, or gone?” You are hiring one person, so the honest answer involves documentation, conventional code another engineer can pick up, and your ownership of everything. “That won’t be a problem” is a problem.
4. “How would another engineer take over if we part ways?” The good answer is boring: standard framework, standard structure, readme, your accounts. If the answer implies you are locked to them, believe it.
5. “How do you decide something is done?” You are listening for testing, a definition of done, and demos of working software. If “done” means “I pushed the code,” quality is your job now.

What are the red flags in a proposal?

Red flag	What it usually means
Open-ended hourly on a vague scope	The estimation risk is yours; the meter runs while scope is discovered
No questions asked about your business	They are building from a template, not for your operation
“We should rebuild all of this first”	Sometimes true, often the most billable possible diagnosis
A price far below the market range	The gap reappears later as rework, delay, or abandonment
Yes to every feature, no pushback anywhere	Nobody is steering; you are buying labor, not judgment
Accounts and repos created under their name	Lock-in, whether intended or not

On the price flag: sanity-check any quote against real ranges before believing it. I published the ones I use in how much custom software costs, and a bid at a third of the bottom of a range is not a bargain, it is a forecast.

How do you structure the engagement so you cannot get badly burned?

The structure matters more than the person, because it caps the damage of a wrong pick:

1. Start with a small, paid, fixed-scope milestone. One workflow, a defined deliverable, a real price, typically in the $2,000 to $8,000 automation tier. You are buying working software and a preview of how this person operates. Never start a $50,000 relationship at $50,000.
2. Own everything from day one. The code repository lives in your GitHub organization. Hosting, domain and third-party services are registered to your accounts, with the engineer invited in. This single habit removes most of the horror stories, including the classic hostage negotiation over a domain name.
3. Demos of working software, weekly. Not status reports, not percentage complete: a screen you can click. Software that cannot be demoed is not behind schedule, it does not exist yet.
4. Fixed scope per phase, always. After each milestone, scope the next one fresh with what you both learned. This keeps estimates honest and gives you a clean exit at every boundary.
5. Put maintenance in writing before launch. Who fixes bugs, at what rate, with what response time. The cheapest moment to negotiate support is while they still want the project.

Quick answers

Do I need a detailed spec before contacting anyone?

No, and a rigid spec written without an engineer often locks in the wrong ideas. Bring the business problem, the current workflow, and your budget range. A good engineer turns that into scope with you; that conversation is itself part of the evaluation.

Marketplace or referral?

Referrals from someone whose project you can actually see beat marketplaces, because longevity is visible. Marketplaces work if you apply everything above and ignore the review stars; five-star ratings measure politeness, not whether the software survived two years.

Do I need a contract?

Yes, a short one: scope, price, payment schedule, and a clause stating you own the code and all accounts. If a freelancer resists the ownership clause, that is the cheapest red flag you will ever get.

I already got burned. Can the project be saved?

Usually, and often without a full rewrite. A rescue starts with an audit of what exists, then the same structure as above applied from wherever the code stands. If you are in that spot, the free audit below is exactly for this: send me what you have and I will tell you honestly whether it is salvageable, and what it would cost either way.