The short version
- You cannot judge the code, so judge the things around it: live URLs you can open, a written scope, a repository in your own account, and a way to watch progress.
- Ask what they would need before quoting. Anyone who prices a build off a two-sentence description is guessing, and you pay for the guess.
- Make the first commitment small. A short paid scoping engagement gets you a plan you own and a look at how they work, before you sign off months of it.
- Get IP assignment in writing. In many places the default is that the developer owns what they wrote unless the contract says otherwise.
- US freelance web developers with real production experience generally run $75 to $150 an hour. Well below that usually means offshore or junior, which can still work but changes what you verify.
Hiring a freelance web developer is uncomfortable for a specific reason: you are buying something you cannot inspect. With most purchases you can judge the thing itself. With software you are judging a person, a process, and a promise, and the work only becomes visible once you have already paid for a chunk of it.
The good news is that you do not need to read code to hire well. Almost every project that goes wrong does so for reasons that were visible before anyone wrote a line: no written scope, no clear owner of the code, a price that was a guess, and no way to see progress. Those are all things you can check.
What you are actually buying
You are not buying hours and you are not really buying code. You are buying a working thing plus the ability to keep it working after the developer leaves. That second half is the part people forget to specify, and it is what separates a project you own from one you are renting.
Concretely, a finished engagement should leave you with:
- A live product on hosting that is in your name, not theirs
- A code repository in your account, with the developer added as a collaborator rather than the other way around
- Accounts for every third-party service in your name, with you paying the bills directly
- Enough documentation that a competent stranger can run the project locally
If you only take one thing from this page, take that list. A developer who sets those up by default is telling you how the relationship ends before it begins, which is exactly when you want to know.
Freelancer, agency, or hiring in-house
These are genuinely different products and the right answer depends on what you are optimising for. I am a freelancer, so read the next bit with that in mind, but the honest version helps you more than a sales pitch would.
| Freelancer | Agency | In-house | |
|---|---|---|---|
| Cost | Lowest | 2–3× a freelancer | Highest, and fixed |
| Speed to start | Days | Weeks | Months |
| Continuity risk | High | Low | Medium |
| Who you talk to | The person building it | Usually an account manager | Your employee |
| Breadth | Narrow and deep | Design, copy, engineering | Whatever you hire for |
When a freelancer is the wrong answer
If the work needs design, brand, copywriting, and engineering running in parallel on one deadline, one person will become the bottleneck and you will feel it. If the thing being built is business-critical from day one and cannot afford a gap, the continuity risk is real: people get ill, take other work, and occasionally vanish. And if you want someone in a standup every morning who knows your business the way an employee does, you want an employee.
When a freelancer is the right answer
Most first versions. When scope is clear enough to write down, when you want the person doing the work to be the person you talk to, and when paying agency overhead for project management you do not need is the main thing standing between you and a shipped product.
Ten questions to ask, and what a good answer sounds like
You are not testing technical knowledge. You are testing whether they have finished things before and thought about what happens afterwards.
- Can I see three things you have built that are live right now? Good answer: URLs you can open, not screenshots. Anything not live should come with a plain reason.
- Which parts of those did you personally build? Good answer: a specific, slightly boring breakdown. Vagueness here is the most common way portfolios are inflated.
- What would you need from me before you could quote? Good answer: a list of questions. Anyone who quotes a build off a two-sentence description is guessing, and you will pay for the guess.
- What is most likely to go wrong with this project? Good answer: a real risk, named. “Nothing” means they have not thought about it or are not telling you.
- How will I see progress? Good answer: a URL you can click, updated as work lands. Not a weekly status email.
- Where will the code and the hosting live? Good answer: your accounts. See the earlier list.
- What happens if we disagree about whether something is finished? Good answer: they point at the written scope. If there is no scope, there is nothing to point at.
- What is not included? Good answer: a real list. Content, images, ongoing maintenance, and third-party subscriptions are the usual surprises.
- Who fixes it if it breaks a month after launch? Good answer: a stated arrangement, paid or unpaid, with a time limit.
- Have you worked on something like this before, and what would you do differently? Good answer: a specific regret. Experienced people have them.
Red flags
- No live URLs. Screenshots and mockups are not evidence that something shipped.
- A price before a scope. A number produced without questions is a number that will change.
- Reluctance about repository access.There is no good reason for the code you paid for to live only in someone else's account.
- Large upfront payment for the whole project. A deposit is normal. Paying the full amount before anything exists is not.
- Timelines with no milestones.“About three months” with nothing in between gives you no way to tell early that it is going wrong.
- Every question answered yes. Someone who has never pushed back on any part of your idea is managing you, not advising you.
What to ask to see before you sign
Three artefacts, and all three are reasonable to ask for:
- A written scope. What gets built, in what order, what it costs, and roughly when. This is the single highest-value document in the relationship and most disputes trace back to not having one.
- A reference you can actually contact. Not a testimonial on their site. A person who will answer an email.
- A sample of their handover. A readme from a previous project, with the client details stripped out, tells you more about how a project ends than any portfolio piece.
Structure the first piece as a paid test
The best protection available to you is not a contract clause. It is making the first commitment small.
Instead of signing off a three-month build with someone you met last week, pay for a short scoping engagement first: a week or so that produces the architecture, the build plan, and a fixed price for the real work. You end up with a document you own and can take to another developer if you want to, and you have watched this person work before committing to months of it.
Good developers tend to like this arrangement, because estimating properly is work and they would rather be paid for it than give it away. Someone who refuses any paid discovery and pushes straight for the full contract is optimising for the signature.
The contract points that actually matter
You do not need an elaborate agreement. You need four things stated plainly:
- IP assignment. The code becomes yours on payment. Say it explicitly, because in many jurisdictions the default is the opposite.
- Payment tied to milestones. Not dates. Deliverables.
- What happens on exit. Repository handover, documentation, and account transfers, listed.
- A defined change process. Scope will change. Agree now how a change gets priced, rather than arguing about it later.
What it costs
US freelance web developers with real production experience generally run between $75 and $150 an hour, with AI and specialist work higher. Rates substantially below that usually indicate an offshore team or someone early in their career, both of which can work out well, but change what you need to verify.
For most projects, fixed price beats hourly from your side. It moves the risk of a bad estimate onto the developer, and it forces the scope conversation to happen up front rather than in month two. Hourly makes sense for small, open-ended work where writing a scope would cost more than the work itself.
For what this looks like in practice, my own engagement types and starting prices are published, including a scoping sprint that gets credited against the build if you go ahead.
