Hiring guide
How to hire a freelance developer in India (2026): a buyer's vetting guide
By Samuel Marndi · Updated
The short answer
Hire for the three things a portfolio cannot show: whether they can explain a trade-off in plain language, whether they will still answer your message in month seven, and whether the code is yours in writing. Everything else — frameworks, years of experience, the look of their own website — is a weaker signal than any of those three.
The single most useful step is a small paid trial task, two to four hours of real work on your actual project, before you commit to the whole thing. It costs a few thousand rupees and tells you more than a week of interviews: how they ask questions, how they handle an ambiguous requirement, whether they hit a date, and what their work looks like when nobody is watching.
First decide what you are actually buying
Most bad engagements start here, not at the hiring stage. "I need a developer" describes four different purchases, and the one you pick decides how you pay, how you measure progress and what happens when the scope moves. Getting this wrong is why projects end in a dispute about whether something was "included".
| What you are buying | It fits when | It goes wrong when |
|---|---|---|
| A finished thing — a website, an app, an integration | The outcome is describable and you want a fixed price against it | The scope is still moving, so every change becomes a negotiation |
| Ongoing capacity — a few days a month, indefinitely | You have a steady trickle of changes and want someone who already knows your system | There is not actually enough work, and you pay for availability you do not use |
| A specific problem solved — it is slow, it is broken, it will not scale | You know the symptom but not the cause | You have asked for a fix when you needed a diagnosis first |
| A decision — build or buy, which stack, is this feasible | You are about to spend serious money and want to be sure it is on the right thing | You hire a builder for it, and get a build recommended |
Where to look, and what each source quietly selects for
Every channel filters the pool before you see it, and none of the filters are about competence. Knowing what each one selects for tells you what to compensate for.
| Where | What it selects for | What it hides |
|---|---|---|
| Marketplaces (Upwork, Fiverr, Freelancer) | People who have optimised a marketplace profile and can afford to bid low | Whether they will still be reachable once the platform is out of the loop |
| A referral from someone you trust | Someone who delivered at least once, for someone who will tell you the truth | Whether their strength matches your problem — a great WordPress person is not an app developer |
| LinkedIn or a cold approach | Availability and self-presentation | Almost everything; a polished profile is the cheapest thing to produce |
| GitHub, or a technical community | People who write code in public, which is a real signal | Communication skill, reliability, and whether they want client work at all |
| Their own site, found by search | Someone who has published their prices, process and reasoning, and can be checked against it | Nothing much — but you still have to verify it, which is what the rest of this page is for |
How to read a portfolio when you are not technical
A screenshot proves someone had access to Figma. Treat the portfolio as a list of claims to verify, not as evidence, and check it the way a customer would.
- Open the live site or install the app, on your phone. Not the case study — the real thing. Does it load quickly on mobile data? Does anything look broken?
- Ask which parts were theirs. On agency work, "I built this" can mean one screen. The honest answer is specific: "I did the backend and the payment integration, someone else did the design."
- Ask who maintains it now. If they still do, after two years, that is the strongest signal on the page — somebody kept paying them.
- Ask what they would change if they rebuilt it. Anyone good has an answer, usually a slightly embarrassed one. "Nothing" means they have not looked at it since, or they are not reflective about their work.
- Check one thing they cannot stage: ask for a client you can call. Not a testimonial — a phone number.
The eight questions that actually separate people
These are chosen because they are hard to answer well without experience, and because a vague answer to any of them is itself the information you wanted.
- "Walk me through how you would approach this, before you quote." You are listening for questions back. Someone who quotes without asking anything has not understood the job, or does not intend to.
- "What is the riskiest part of this project?" Every real project has one. Naming it is a sign of judgement; "it's all straightforward" is a sign of either inexperience or a sales pitch.
- "What would make you say no to this?" People who have been burned have boundaries. People who will say yes to anything will say yes to a deadline they cannot hit.
- "Who owns the code when it is finished, and will you put that in writing?" The correct answer is you, in writing. Hesitation here is the most expensive red flag on the list.
- "What happens if you are ill, or on a flight, when something breaks?" You are not looking for a promise of immortality. You are looking for a real answer: documented access, a named backup, a stated response window.
- "What do you need from me, and when?" Projects stall on the client side more often than the developer side. Someone who has delivered before knows this and will tell you upfront.
- "Show me a project that went badly and what you did about it." Everyone has one. The answer tells you how they behave under pressure, which is the only time it matters.
- "What is not included in this price?" The useful version of "what is included". Hosting, content, third-party licences, app store fees, post-launch changes — the answer should be ready, not improvised.
The paid trial task: the one step that replaces guesswork
Pick a small, real, self-contained piece of your project — one page, one integration, one screen, a performance audit — and pay for it at the person's normal rate. Two to four hours is enough. Agree what "done" means in writing before they start.
It is the only part of hiring that generates evidence instead of impressions. And it is cheap: at ₹1,500 an hour a four-hour trial costs ₹6,000, against a wasted project that costs you months. Do it with two candidates if the project is large.
- Did they ask clarifying questions before starting? The best signal on the list.
- Did they deliver when they said they would? If a four-hour task slips by a week, a three-month project will slip by a quarter.
- Did they explain what they did, in language you understood? You will be reading these updates for months.
- Did they flag something you had not thought of? That is what you are actually paying a good developer for.
- Did they hand over cleanly — code in your repository, access you can use, nothing locked to their machine?
- Never ask for free "test" work. Anyone good declines it, so the practice filters out exactly the people you wanted and leaves you choosing among those with nothing better to do.
What a real quote looks like next to a vague one
A one-number quote cannot be checked, compared or disputed, which is usually the point. Ask for the itemised version — and notice that asking for it is itself a test.
| A quote you cannot check | A quote you can |
|---|---|
| "Website: ₹60,000" | Each page or screen listed, with a price against it |
| "Including SEO" | Named deliverables: titles and meta descriptions, schema, sitemap, Search Console set up |
| "2–3 months" | Milestone dates, with what is delivered at each and what is needed from you before it |
| "Hosting included" | Which host, whose account it is in, what it costs from year two, and who pays it |
| "Support included" | For how long, covering what, with what response time, and what it costs after that |
| Silence on third-party costs | Domain, SSL, app store fees, SMS and email credits, paid plugins — listed and priced, billed at cost |
| No mention of the code | A line stating that the source code and all accounts transfer to you on final payment |
The five things that must be in writing before you pay anything
This does not need a lawyer or a twenty-page agreement. Five clear paragraphs in an email that both of you have replied to will prevent almost every dispute that actually happens.
The detail on each of these — including what Indian copyright law does and does not give you by default — is in red flags when hiring a developer.
- Scope. What is being built, listed. And explicitly, what is not.
- Ownership. That the source code, designs and content become yours on final payment, assigned in writing. In India this does not happen automatically with a contractor.
- Milestones and money. What is paid when, against what deliverable. Never the full amount upfront; never nothing upfront either.
- Handover. The list of accounts, repositories and credentials that transfer, and that they are in your name — ideally from day one, not at the end.
- Support. What happens after launch: for how long, covering what, at what cost once that window closes.
What one person genuinely cannot cover — and what to do about it
An honest version of this page has to say this. One person is one person: no bench, no night shift, no second opinion down the corridor. If you need 24/7 cover with a contractual response time at three in the morning, you need a team, and anyone telling you otherwise is selling.
What a single accountable person does give you is no account manager between you and the work, no handover to a junior after the pitch, and one phone number that is answered by the person who wrote the thing. For most small and mid-sized businesses that trade is worth making — provided the single-person risk is actually mitigated rather than ignored.
- The code lives in your repository, under your account, from the first commit. Not theirs.
- Every third-party account is in your name — domain, hosting, cloud, app stores, payment gateway — with you as owner and them as a user you can remove.
- There is written documentation: how it deploys, where the environment variables live, what breaks first. Ask for it as a milestone deliverable, not a favour.
- There is a named fallback — another developer who could pick it up, and ideally has seen it.
- Response times are stated honestly, including when they do not apply. "Within four working hours, Monday to Saturday, 9am to 8pm IST" is useful. "24/7" from a one-person operation is not.
If you already know the shape of the work, go straight to the page that prices it.
FAQ
Related questions
How do I know if a freelance developer is any good before I hire them?
Pay for a small piece of real work — two to four hours on your actual project, at their normal rate — and watch five things: whether they asked questions first, whether they delivered on the date they gave, whether they explained it in language you understood, whether they flagged something you had missed, and whether the handover was clean. That evidence is worth more than any interview, and at a typical ₹1,500 an hour it costs about ₹6,000.
Is it safe to hire a freelancer instead of a company?
It is safe if the single-person risk is mitigated rather than ignored: your code in your own repository from the first commit, every third-party account in your name with you as owner, written documentation as a delivered milestone, a named fallback developer, and honest response times. Where it is not safe is a contractual 24/7 obligation — one person cannot meet that, and anyone promising it is selling.
What should I never do when hiring a developer?
Never pay the full amount upfront, never accept a one-number quote you cannot check line by line, never let the code or the accounts sit under the developer's own login, and never ask for free trial work — anyone good declines it, so you end up choosing from the people with nothing better to do.
How much deposit is normal for a freelance developer in India?
20–40% to start is normal and reasonable, with the rest against delivered milestones. Full payment upfront is not normal. Nothing upfront is not reasonable either — a freelancer taking on a month of work has no bench to absorb a client who disappears, and a sensible deposit is what makes a fixed price possible.
Who owns the code I paid a freelancer to write?
Not automatically you. Under Indian copyright law the author is the first owner of what they write, and an independent contractor is not an employee, so ownership passes only if it is assigned in writing. One sentence in the agreement fixes it: that all source code, designs and content are assigned to you on final payment. Get it in writing before work starts, not after. This is a general explanation rather than legal advice — for anything substantial, have a lawyer look at the agreement.
What questions should I ask a freelance developer in an interview?
The most revealing are: walk me through your approach before you quote; what is the riskiest part of this; what would make you say no; who owns the code and will you put that in writing; what happens if you are unavailable when something breaks; what do you need from me and when; show me a project that went badly; and what is not included in this price.
Should I hire a freelancer from a marketplace or directly?
Marketplaces give you escrow and a dispute process, which has real value on a first, small engagement with someone you do not know. They also select for people who bid low and optimise profiles, and the relationship usually has to leave the platform to become a long-term one. For ongoing work, hiring directly against a written agreement tends to cost less and work better — the platform fee was buying you protection you no longer need once there is a track record.
How long should a small website or app project take?
A small business website is typically three to six weeks, an app MVP two to four months, with the variance driven more by how quickly you supply content, approvals and access than by the development itself. Be suspicious of a much shorter promise — it usually means a template with your logo on it, which is a legitimate product but a different one, and should be priced as such.