You can't read the code, so don't try to judge it. Judge what you can see: where the developer came from, the work they can show you, the questions they ask on the first call, and how they handle a small piece of paid work before you commit to a big one. All of that happens before there is a quote, and it tells you more than the quote will.
Most advice on this is written for startup founders hiring an employee. That's a different problem. If you run a business and you need a system built, you're hiring a firm or a freelancer for a project you'll live with for years. The question is whether you can trust them with it.
Start with who other owners would hire again
The best source is other business owners. Ask them who they would hire again, and what that person built for them. Plenty of owners have used a developer they'd never hire twice, so the first half of the question filters those out. The second half matters too. Someone who built a good marketing site may not be the right person for the system that runs your warehouse.
The software you already like is the next place to look. If a supplier's ordering portal or another company's booking system works well, ask who built it. That's finished work you've already used as a customer, which is better evidence than any portfolio.
Freelance marketplaces are fine for small, well-defined jobs. They're a harder fit for something you'll depend on for years, because the platform is built around finishing a job, and you need someone who will still answer the phone in year three.
Aim for a shortlist of three. Ten conversations blur together, and by the seventh you'll be comparing charm.
What to check before the first call
You can do all of this without being technical, and without taking up anyone's time.
Use something they built. A live site or app you can open, rather than a screenshot. Does it load quickly on your phone? Can you find what you came for? You're a normal user here, and a normal user's opinion is the one that counts.
Talk to someone who hired them. Ask for a past client you can call, then ask that client one question: what happened when something went wrong? Every project has a bad week. You want to know how the developer behaved during it.
Ask how long their clients stay. A developer whose clients come back for a second and third project is doing something right. One who can only show you first projects might be new, or might not get invited back. Ask which.
Look at who owns what. If their past clients' domains and hosting sit in the developer's own accounts, yours will too. I've written about why you should own your code, your domain and your accounts, and it's worth reading before you sign anything.
A client came to me after their previous developer left them with an unfinished site, missing access and almost no documentation. It took about two weeks before I could safely make meaningful changes. The first job was tracking down credentials, working out what they actually owned and reconstructing how the system worked.
The warning sign was something they could have checked before hiring. Who owns the accounts, the code and the access if the relationship ends? If the answer isn't a clear "you do," that's a problem. They didn't ask, so before the project could move forward at all, they paid for hours of recovery work. A good developer makes it easy for someone else to take over, because one day someone else might have to.
What the first call should sound like
A good first call is mostly them asking you questions. About the business, what the work looks like on a normal Tuesday, what happens when it goes wrong, and what you've already tried. If they're describing their technology in the first ten minutes, they're selling. I've written about what a good discovery call covers from the other side of the table.
Listen for these.
They tell you what they wouldn't build. "You don't need that part yet" or "a tool you can buy does this for fifty dollars a month" costs them money to say. Someone who says it anyway is working for you.
They say what they don't know yet. "I'd need to see your current system before I could tell you" is a good answer. A confident number on a first call is a guess, and a guess is a quote that moves later.
They can explain your problem back to you. Ask them to. If you recognize your business in what they say, they listened. If you hear a list of features, they were waiting for their turn to talk.
They're willing to say no. Some work isn't a fit, and a developer who knows that saves you months. Why I turn down work I could technically do covers when I'd say it.
Pay for something small first
Before you commit to the whole build, pay for a small piece of it. That could be a short paid discovery that ends in a written scope, something like the one-page brief that saves us both weeks. Or it could be a first phase that delivers one working thing. Either way it's small enough that if it goes badly, you've lost a few weeks instead of a year.
Then watch how they work. Did they deliver on the date they gave you? When something slipped, did they tell you early, or did you find out when you asked? Is what they handed over the thing you both wrote down? Could they answer your questions in plain English? None of that needs a technical eye, and none of it changes when the project gets bigger. It just costs more.
If a developer won't do a small paid first step, ask why. There can be a good reason. You should hear it before you sign up for the whole project.
When to walk away
Some warning signs are visible to anyone.
- Nothing goes in writing. Not the scope, not the price, not the timeline, not who owns what. "We'll figure it out as we go" means you'll figure it out as you pay.
- They want the domain and the accounts in their name, to keep things simple.
- Every risk you raise gets waved off. Every project has a risky part, and someone who can't name it hasn't looked.
- There's a deadline on your decision. A discount that expires Friday is pressure, and pressure is for people worried you'll think it over.
Once the quotes come in
A shortlist of good developers can still send back three very different numbers. That's normal. It usually means they pictured three different projects. Nobody taught you how to read a software quote is the next step, and how much custom software costs gives you the ranges to hold them against.
If you want someone technical on your side before you sign, pick someone who isn't bidding on the work. They're the one person in the process with nothing to gain from which quote you choose.
