Hiring a web developer starts with knowing what you are actually buying — a landing page, a multi-page site, an online store or a web app — then picking a person by live links to their work and by the questions they ask you, and paying in milestones with demos in between. Everything else is detail, and it is exactly those details that get websites rebuilt twice.
Here is the path, step by step, for a client with no technical background who does not want a folder of pretty pictures instead of a working site. General rules for working with freelancers are in how a client finds a reliable freelancer — this one is about development only.
Step 1. Decide what you actually need
Telling a developer «I need a website» is about as useful as telling a car dealer «I need transport». Each type of project needs a different person, a different timeline and a wildly different budget.
- Landing page — one page for an ad campaign or a single product. Fastest and cheapest. You need a front-end person with an eye for design.
- Multi-page site — company, services, blog, forms. Usually built on a ready-made CMS. You need someone who can also set up the admin panel, not just the layout.
- Online store — catalogue, cart, payments, shipping, stock integration. This needs real e-commerce experience, not «I have made websites».
- Web app — user accounts, calculations, roles, a database. The longest and priciest option, and never hire for it from a portfolio full of landing pages.
Until you have picked one item from that list, any price estimate is guesswork. If putting it into words is hard, run the task through the free brief generator — it asks the questions a decent developer will ask you anyway. The longer version lives in how to write a brief for a freelancer.
Step 2. How to judge a developer when you are not one
You do not need to read code to tell a professional from a random person. Four moves are enough.
Ask for live links, not screenshots. An image proves only that someone can produce images. Open the site on your phone, poke the forms, watch it load. No links at all is already an answer.
Ask what exactly THEY did. On team projects one person designed, another built the front end, a third wired up payments. A good answer sounds like: «the design is not mine, I did the front end and the payment integration». A bad answer is «that is my project» — followed by silence.
Ask how they would approach your task. Not «how much», but «where would you start and why». You will hear instantly whether they are thinking about your project or just chasing the order.
Notice whether they ask you questions. This is the single most reliable signal. The one who asks who your customers are, where traffic comes from and what should happen after the form is submitted is almost always the one who finishes the job.
The rule that saves money: whoever asks questions before payment is asking instead of inventing on your behalf. Whoever asks nothing will invent — and you will pay for it in revisions.
Step 3. Questions you can copy straight into the chat
- Show me 2–3 live links to projects of the same type as mine. What did you personally do on them?
- What would you build it with and why? What happens if in a year I need someone else to extend it?
- How will you split the work into stages and what will I see at each one?
- What do you need from me to start: texts, photos, access?
- What is included in the price and what counts as extra work?
- How many revisions are included per stage, and how are extra ones charged?
- What will you hand over at the end: code, access, instructions?
- What about support after launch — for how long and on what terms?
Eight questions, five minutes of your time. The weak candidates filter themselves out.
Step 4. Red flags
- Agrees to everything. «Sure, no problem» to every wish you voice is not service, it is the absence of analysis.
- Quotes instantly, without seeing a brief. That number is backed by nothing and will grow later.
- No live work at all. Only mockups in an archive, or «that one is under NDA» for every question.
- Refuses intermediate demos. «I will show you when it is done» is the phrase after which nothing is usually shown.
- Disappears for a week. Silence before the money means silence after the money, only more expensive.
- Wants the full sum up front and moves chat and payment off the platform. How that ends is covered in safe deals and protection from scammers.
Step 5. Milestones instead of one big payment
Split the project into at least three parts: prototype and structure, design and layout, features and launch. Each stage gets its own payment and sign-off. Worst case you lose one stage, not the whole budget — and you can walk to another developer with the finished part in hand.
Intermediate demos are not bureaucracy, they are insurance. A live link once a week, even to an ugly draft, shows real progress. Neat «everything is on track» reports show nothing. How to sign work off without drowning in revisions is in accepting the work and handling revisions.
Step 6. What you must get at the end
This is where clients lose the most. The site works, everyone is happy, and a year later you discover it is not yours.
- Source code — in your repository or as an archive, not «I keep it, message me if anything».
- Hosting and domain registered to you. Your email, your card. Not the developer. Ever.
- Access: admin panel, hosting panel, database, analytics, mail — as a list, with passwords.
- A short handover: how to add a page, where to change the phone number, where enquiries land. One page of text or a 15-minute video is enough.
A domain in someone else's name is not a technical detail. It means your business runs on a handshake with a person you might one day fall out with.
Step 7. Support after launch
The site goes live and three days later the enquiry form breaks. Who fixes it, at whose cost? Agree before the start: how many days after delivery bugs are fixed free, what counts as a bug versus a new task, and the rate for further work. One line in the agreement removes 90% of future resentment.
Step 8. The lowest-price trap
The classic: pick the cheapest of ten bids, get a half-working site, then pay a second developer to untangle and rebuild it. Total cost — more than a solid mid-level person would have charged upfront.
What does a website cost? Honestly: it depends on the project type, the market and the developer's experience, and the gap between a landing page and a web app is easily tenfold. Aim at the median of the bids, not the minimum: if nine people quote similar numbers and the tenth is three times cheaper, they either misunderstood the task or will not finish it. The budgeting logic is unpacked in what freelance work costs.
Client checklist before you start
- Project type chosen: landing, site, store or app.
- A brief exists, at least one page of it.
- Live links from at least three candidates reviewed.
- Asked «how would you approach my task» and got a thoughtful answer.
- Work split into stages, each with its own payment.
- Intermediate demos by live link agreed.
- Written down what gets handed over: code, access, domain, hosting.
- Support and post-launch rates discussed.
- Deal and chat stay on the platform, not in private messages.
What to do next
Finding a programmer is easy. Choosing one who asks the right questions and delivers work that can be handed on is the hard part. Run the checklist top to bottom: it takes half an hour and saves you roughly one rebuilt website.
Once the brief is ready, post your project and collect bids, see who asks what in the projects section, or browse the freelancer catalogue and message the people whose live work you liked. A freelance developer chosen by these rules costs less than an in-house hire and is safer than a random one.
