To choose a freelance full-stack developer, check real shipped work, production links, role clarity, code ownership terms, communication process, and milestone delivery style. Do not hire on cheap pricing or portfolio screenshots alone. You need proof the developer can finish the backend, handle deployment, and hand the project over cleanly.
Look for shipped production work
Screenshots prove nothing. Anyone can paste a Figma mockup or a half-built dashboard into a portfolio. What you actually want is a live URL you can open right now, click through, and break.
When I review another developer's work, or present my own, I look for the unglamorous parts: does login work, does the form validate, does the search return sensible results, does a payment go through, does the page survive a refresh. A polished landing page tells you someone can style a hero section. A working checkout tells you someone can finish a backend.
Ask for at least one production link where the developer owned more than the frontend. Frontend-only work is fine for a brochure site, but a full-stack hire is supposed to handle the database, the API, the auth, and the deployment too. If every example is "I built the UI and someone else wired it up," you are not hiring a full-stack developer — you are hiring a frontend developer with a broader job title.
On CarVendors, a live UK used-car marketplace, I worked solo across frontend, backend, data workflows, and deployment. That included vendor onboarding and dashboards, listing management, multi-field search and filtering, reviews, GDPR and cookie consent, a data import and scraper pipeline for vehicle listings, and the deployment automation around all of it. That is the kind of end-to-end evidence worth asking for: not "here is a screen," but "here is the thing running, and here is everything underneath it."
Check role clarity on team projects
Most impressive portfolios are team projects. That is not a problem on its own — it becomes a problem when nobody can tell you what the developer actually did.
Ask a direct question: on this project, what did you personally build, and what did the rest of the team build? A confident answer sounds specific. "I built the vendor dashboard, the search API, and the deployment pipeline; another developer handled the marketing site." A vague answer sounds like ownership theatre — "I led the project," "I was involved in the architecture" — with no concrete component you can point to.
Solo projects are clarifying for exactly this reason. When I say I was the only developer on CarVendors across frontend, backend, and DevOps, there is no ambiguity about who handled the database schema or who configured the deploy. You can hold the whole thing against one person. On a freelance hire, that single-owner clarity is what you are paying for, so make sure you can establish it before money changes hands.
Code ownership and handover
This is the section most clients skip, and it is the one that hurts later. Decide up front: when the project ends, who owns the code, and how does it reach you?
A freelance build should leave you with the repository, the ability to deploy it yourself or hand it to another developer, and enough documentation that you are not held hostage. If a developer is cagey about giving you the source, or the "handover" is a zip file with no README and no environment notes, you have bought a dependency, not an asset.
Put it in writing. The contract should state that you own the code on final payment, name the hosting and accounts involved, and define what handover means in practice — repo access, deployment instructions, environment variables documented, and a walkthrough if needed. I treat internal tools the same way on business systems work: documented and handed over properly, so the team is not dependent on me to keep the lights on. That is the standard to expect from anyone you hire.
Communication and milestones
How a developer communicates during a small first task predicts how they will communicate during a hard month. Watch the early signals: do they reply within a sensible window, do they ask clarifying questions before building, do they tell you when something will slip instead of going silent.
Milestone style matters just as much. I prefer breaking work into visible chunks — a planning pass, then features delivered in slices you can review as they land, rather than a single big reveal at the end. CarVendors moved that way through small, reviewable increments rather than one opaque delivery block. Frequent progress reviews let a client course-correct early, which is cheaper for everyone than discovering at the end that the build went the wrong direction.
Agree on the rhythm before you start: how often you will see progress, where it lives, and what "done" means for each milestone. A developer who resists that structure is telling you something.
Red flags
A few patterns reliably predict trouble:
- Only screenshots, no live links. If nothing is clickable, assume nothing is finished.
- Price as the headline. A quote far below everyone else usually means a corner is being cut — often the backend, deployment, or handover.
- No role clarity on team work. "I led it" with no nameable component is a warning.
- Vague on ownership. Hesitation about who owns the code, or who controls the hosting, gets worse after launch, not better.
- No questions back. A developer who quotes a price without asking about scope has not understood the project, or does not care to.
- Disappears under pressure. Slow or silent replies on the first small task will not improve on the hardest one.
None of these are automatically disqualifying in isolation. Two or three together is a clear pass.
Questions to ask before hiring
Use these in a first call. Honest answers are short and specific.
- Can you show me a live production URL where you owned the backend and deployment, not just the UI?
- On that project, what did you build personally and what did the team build?
- When we finish, do I own the code, and how do you hand it over?
- How do you split a project into milestones, and how often will I see progress?
- What happens after launch if something breaks — are you reachable?
FAQ
Should I hire the cheapest freelance developer?
No. Price is a signal, not the decision. A very low quote often means the unglamorous, expensive parts — backend, deployment, handover — are being skipped. Compare what is actually included, then weigh price against shipped evidence and clear ownership terms.
How do I verify a developer's portfolio is real?
Open the live links and use them. Try the login, the search, a form, a payment if there is one. Ask exactly which parts they built. Real work survives clicking; screenshots and "I was involved" answers do not.
Solo freelancer or an agency?
Either can work. A solo developer gives you single-owner clarity and direct communication; an agency gives you more hands and cover for absence. For a focused build, I find one accountable owner — and a clean handover — beats a diffuse team you cannot question.
Next step
If you are weighing up a build and want a developer who can take it from empty repo to live product, see my web application development service for how I scope, build, and hand over full-stack projects end to end. Tell me what you are building and I will give you an honest read on it.