How to hire a developer in India

Who this guide is for, and what it will not do

This guide is written for someone who needs software built and does not write code: a business owner digitising part of their operation, a founder with a first product, a manager who has been told to find a vendor. It assumes you are intelligent and busy, and that you have probably been burned or have heard stories of people who were. It will not teach you to program. It will teach you what to ask, what to verify, and what to put in writing, which is most of what separates a good outcome from a bad one.

It is deliberately protective. Hiring a developer is one of the few purchases where the buyer cannot easily judge the quality of what they are buying until long after they have paid. That asymmetry is the reason for every recommendation below. Each one exists to turn something you cannot judge into something you can.

I am a developer, and I would rather you hire well than hire me carelessly. Where my own interest and your advice might pull in different directions, I say so.

Step one in depth: the one page you must write

Every successful project I have seen began with a short document written by the person who owned the problem. It is not a specification. It is a page that answers six questions: who is this for, what problem do they have, what do they do today, what is the single thing that must work on day one, what is deliberately left for later, and how will you know it worked.

Writing it forces decisions you would otherwise postpone to the most expensive moment. If you cannot say who the product is for in one sentence, you are not ready to hire, and no developer can fix that for you. They will quote against their guess of your intent and you will both be disappointed.

The page also becomes your yardstick. When a vendor proposes a feature, you can ask whether it serves the thing that must work on day one. When a quote arrives, you can check it against what you wrote. Without it, you are negotiating against a vendor who has written the only document.

Add two or three apps or sites you like and say what you like about each. It is the cheapest way to communicate taste, and it tells a developer more about your expectations than a paragraph of adjectives.

Step two in depth: freelancer, studio, agency or employee

People spend a great deal of energy choosing a particular vendor before they have decided what kind of vendor they need. The kinds differ more than the individuals within them, so decide the kind first.

A freelancer is a single person. You get direct communication, flexibility and a lower price, and you carry the risk of a single point of failure. A small studio gives you a few people with complementary skills, usually still with direct access to the people building. An agency offers breadth, process and capacity at a higher price and with more distance between you and the work. An employee is the right answer only when software is core to the business and there is work for years, and it is the slowest and riskiest way to start.

For a first product with a clear scope, a freelancer or small studio is usually the best place to begin. For something large, regulated or that needs many specialisms in parallel, an agency earns its price. The comparison on this site gives you a tool for deciding by your own situation.

Whichever kind you choose, mixing is allowed. Many good projects use an independent developer for the build and a specialist for design or a security review.

Step three in depth: where to find candidates, and how many

The best sources are the ones where proof is visible. Published apps in the Play Store and App Store, portfolios with named clients, open-source work you can read, and people your own network will vouch for. Marketplaces and directories can be useful for volume, but treat the profile as a claim and the work as evidence.

Ask people you trust who built the software that they actually enjoy using. Ask founders in your industry. A recommendation from someone who has been through a project, and was happy at the end, is worth more than any number of reviews.

Shortlist three. Fewer and you have no comparison. More and the process becomes a second job, and the differences become noise. Three conversations are enough to see how people differ in how they ask questions, how they handle uncertainty and how they talk about money.

Send each the same one-page brief and ask the same questions. Comparing like with like is the single most useful thing you can do, and it is something most buyers do not do.

Step four in depth: how to verify without being technical

Verification is the part buyers most often skip, because it feels rude or technical. It is neither. Professionals expect it, and the good ones are glad of it, because it separates them from people who cannot back up what they say.

Start by opening two of their shipped apps on your own phone. Use them for a few minutes. Do they load quickly? Do they work if you turn off the connection? Do they feel considered? You do not need to know why something feels good or bad to notice that it does.

Then ask them to take you through one decision they made and would defend, and one they would change. This is the most revealing question I know. Builders have regrets. A person who cannot name one has either not built much or is not telling you the truth.

Finally, ask for a person to call. A previous client, for ten minutes. Ask them how communication was when things went wrong, whether the project was delivered on the terms agreed, and whether they would hire again. People are surprisingly candid.

• Open two shipped apps on your phone.
• Ask for a decision they would defend and one they would change.
• Speak to one past client.
• Ask who will actually write your code, by name.

Step five in depth: scope, milestones and what is not included

A scope is a list of what will be built, in plain language, specific enough that you could tell whether each item was delivered. Screens, features, integrations, user roles, devices supported. It is not a technical document. If you cannot read it, it is not finished.

Next to it goes the list of what is not included. This list is where most disputes are born, and writing it down turns them into discussions held before money has changed hands. Typical entries are features for a later version, third-party fees, content and copywriting, marketing, and ongoing support beyond a stated period.

Then comes the breakdown into milestones. Each milestone should end with something you can test on your own phone or in your own browser, and payment should follow it. This is the control that lets you judge progress without understanding code. It also gives both sides natural points to stop, adjust or part ways with little harm done.

Finally, agree how change is handled. You will change your mind, and so will the vendor, as they learn what is harder than it looked. A short rule, such as 'changes are described in writing, priced, and agreed before they are made', prevents most arguments.

Step five continued: who owns what

Ownership is the clause that matters least until the moment it matters most. In India, as in most places, the person who writes code generally holds the copyright unless it is assigned to you in writing. A conversation or an email thread saying 'you will own it' is not the same as a clause that says so.

Make three things explicit. First, that ownership of the code and designs passes to you on payment. Second, that the repository where the code lives is under your account from the start, with the developer granted access. Third, that the accounts for the app stores, hosting and any third-party services are registered in your name. Each is easy on day one and a painful negotiation on the day of a dispute.

If some components are the vendor's own reusable libraries, ask for the licence terms in writing, so that you know what you may continue to use if you part ways.

Step six in depth: paying, testing and handover

Pay against milestones you have tested, and not on a calendar. A small initial payment to start is normal and fair. After that, each payment follows something delivered. This one rule changes the whole dynamic. The developer is rewarded for results you can see, and you are never funding work you cannot inspect.

Test yourself, on a real phone, using the product as a customer would. Write down what is wrong in plain language. Do not worry that you are not a technician; the person who will use the product is not either, and you are the best proxy for them that the project has.

At the end, expect a handover. The source code in your repository, the credentials and keys in your name, and a short document explaining how the parts fit together and how to run and update the project. Without it you are dependent on the person who built it for every future change.

After launch: the first month and the first year

Launch is the start of the second phase of the project, not the end. Real people use the product in ways nobody anticipated, and problems you could not have found in testing appear within days. Plan for a period of fixes, and agree in advance what it covers and what it costs.

Operating systems change every year. Libraries age and security issues are found. A product that is not maintained slowly stops working. Budget for ongoing maintenance as a recurring line, even a modest one, so that you are not faced with a large emergency bill when something breaks.

Decide who is responsible for what: who monitors, who fixes, who updates the integrations when a provider changes its rules. If the answer is 'the developer', make sure that is in writing and that you know what they charge.

A note on money and taxes

Get invoices that are properly formed. In India, software services are generally subject to GST, and a vendor registered for it should issue invoices that show it. Whether quotes include or exclude GST should be stated, so that you are comparing like with like.

If you are a business, proper invoices matter for your own accounts and for any input credit you may be entitled to. Have your accountant tell you what is relevant to your situation. This guide does not give tax advice.

Be careful of vendors who prefer cash and no paperwork. It may be a convenience, but it also leaves you with no record of what you paid for, which makes any later dispute much harder.

Ten warning signs, collected

1. A quote that is only a total, with no scope behind it.
2. Unwillingness to say who will write the code.
3. A request for the whole payment up front.
4. Keeping the repository or the store accounts in their own name.
5. A fixed date promised before they have read your brief.
6. No questions about your users or your goals.
7. Pressure to decide today.
8. Reluctance to let you speak to a past client.
9. Portfolios made only of screenshots and no live products.
10. Agreement to every idea you have, without ever saying 'not yet'.

One of these should make you pause. Three should make you leave. And remember that people with good intentions fall into some of them by accident, so a conversation is worth having before you walk away.

Three short stories of how this goes wrong, and the one habit that would have prevented each

A founder hired a developer found through a marketplace, agreed a total price by message, and paid half up front. The work arrived in pieces, never quite finished, and when the founder wanted to move to someone else, the repository turned out to be on the developer's personal account and the store account was in the developer's name. The product could not be moved. The habit that would have prevented it: put the repository and store accounts in your name on day one, before any payment.

A shop owner commissioned an ordering app from an agency. The quote was a single figure, and the scope was a two-line email. Halfway through, a series of features the owner assumed were included were quoted as extras, each reasonable on its own and together nearly doubling the cost. The habit that would have prevented it: a written scope with a not-included list, agreed before the first payment.

A small company hired a developer on the strength of a polished portfolio. On delivery, the app crashed on older phones and had no way to recover from a lost connection. The portfolio contained screenshots of a design and no live product. The habit that would have prevented it: open two shipped apps on your own phone, on a modest device, before you decide.

None of these needed a villain. In each, a decent person met a busy buyer who had skipped a simple check. That is the encouraging part of the picture: the protections are cheap, and they are the same few every time.

How the advice changes for different kinds of buyer

If you are a first-time founder with limited funds, spend your effort on the first two steps. A sharp one-page brief and the right kind of vendor will save you more than any negotiation. Keep the first version small, pay in small milestones, and resist features. Your biggest risk is building something nobody wants, not building it badly.

If you run an established business digitising an existing process, your advantage is that you know the process. Your risk is trying to reproduce the paper version screen for screen. Take a developer through one real day and ask them what they would change. The best software for an existing business often removes steps, not adds screens.

If you are inside a larger organisation, you will probably need a formal contract, a vendor registered for GST and sometimes security reviews. Start the paperwork early, because procurement is often the slowest part of the project. And be clear about who in your organisation has the authority to make decisions, because a developer waiting for approval is a developer who is not building.

The whole guide in a paragraph

Write one page about who it is for and what must work first. Choose the kind of vendor before the vendor. Shortlist three and ask each the same questions. Verify with a live app and a phone call. Put the scope, the not-included list, the milestones, the change rule and the ownership in writing. Pay against what you have tested. Take a handover and a backup. Budget for the first month and the first year. If you do those things, you have done more than most buyers, and your chances of a good outcome are much higher than average.