How to Hire a Remote Developer Without Getting Burned

Most remote hires that go wrong don't fail because the developer couldn't code. They fail because of things nobody checked before the contract was signed.

The founder finds out three months in that the developer only worked on a small part of the portfolio project. Or the code sits in the developer's own GitHub, and the server runs on their credit card. Or the invoices kept coming while the product never quite got to a state anyone could try.

I'm writing this from the other side of the table. I've spent more than 10 years building software for clients, most recently as lead engineer on products like DocBee and BD Doctors Directory. These are the five things I'd check if I were hiring someone like me.

1. Find out which part they actually built

A portfolio shows you a finished product. It doesn't tell you who did what.

Pick one project and ask them to walk you through a single decision they made on it, and why. You don't need to follow every technical detail. You're listening for whether they can explain it from the inside.

For example, if you asked me about DocBee, a telemedicine app I was lead engineer on, I'd tell you why the booking system lets the database refuse a second booking for the same slot instead of trusting the app to check. I'd also tell you what goes wrong if you do it the other way. That's the kind of answer you're looking for: specific, and clearly theirs.

A good answer sounds like "I designed the API and built both mobile apps." A vague one sounds like "we built it", with nothing more when you ask.

2. Ask how they'd stop your worst bug

Every product has one thing that must never go wrong. For a booking app, it's two customers getting the same slot. For software sold to many businesses, it's one customer seeing another customer's data. For anything that takes payments, it's charging someone twice.

Ask the developer what your worst bug is and how they'd prevent it.

The answer you want sounds like "the database won't allow it" or "there's a test that tries to break it on every change". The answer to worry about is "we'll be careful".

Being careful doesn't hold up. On a school management system I built, I wrote 338 automated tests for code I had already called finished. They found six real bugs. One of them let a school read another school's data. Careful wasn't enough, and I was the one being careful.

3. Own the code and the accounts from day one

This is the one I'd push hardest on, and it's the one that gets skipped most.

Before any work starts, set these up in your own name and invite the developer in:

• The code repository. Create a GitHub or GitLab organisation for your company and add the developer to it. Don't let the only copy of your code live in their personal account.
• The cloud or hosting account. Your name, your card. They get access, not ownership.
• The domain. Registered to you, at a registrar you can log in to.
• App store accounts. Apple and Google developer accounts in your company's name.
• Third-party services. Payment gateways, email providers, maps and so on, with your company as the account holder.

Then get the contract to say that the rights to the work pass to you once it's paid for. Add an NDA if the idea needs one. I'm not a lawyer, so for anything unusual, have a lawyer look at the contract.

If the code lives in the developer's account and the server runs on their card, you don't really own your product. You're renting it. And you usually find that out at the worst moment, when the relationship ends.

4. Pay for milestones you can click through

Hourly billing with no clear milestones is how budgets drift. Nobody is doing anything wrong, and the product still never quite gets finished.

Split the work into milestones you can check yourself:

• a login that works
• a booking you can actually make
• a payment that shows up in the admin panel
• the app installed on your own phone from a test link

Pay when each one works, not because a month has gone by. For fixed-price work, a deposit of 30–50% upfront with the rest paid by milestone is normal. That's how I work too, and it protects both sides.

If you're unsure about a developer, start with something small and paid: a scoping plan or a review of your existing code. You'll learn how they think, how they write things down and how they handle your questions, before you commit to a big build.

5. Agree how you'll hear from them

Time zone overlap matters less than people think. Updates matter more.

Before you start, agree what a normal week looks like:

• When you'll talk live. One or two calls a week in your overlap hours is usually enough.
• What you'll get in writing on the other days. A short update: what's done, what's next, and anything blocking.
• Where you can see progress. A test version of the app you can open any time, not just screenshots.
• What happens when they're stuck. You want to hear about a problem the day it shows up, not at the next deadline.

Being far apart can help. I work 05:00–23:00 Bangladesh time, which covers the whole UK, European and Gulf working day. For US teams, we talk in their morning and the work moves forward overnight.

A quick checklist before you sign

• They walked you through one real decision on a past project, in their own words.
• They named your worst bug and explained how they'd stop it.
• The repo, cloud account, domain and app store accounts are in your name.
• The contract gives you the rights to the work once it's paid for.
• Payment is tied to milestones you can click through.
• You've agreed when you'll talk and how you'll get updates.

None of this is complicated. It's just easy to skip when you're excited to get started. A good developer won't mind any of it. The good ones would rather you checked.