Hiring an app developer in Noida: the contract, payment and ownership terms that protect you

A business owner in Noida called me last month, upset. He had paid a developer 70,000 rupees to build an ordering app for his cloud kitchen. Half up front, half a few weeks later, all over UPI, all agreed on WhatsApp. The app was "almost done" for two months. Then the developer went quiet. No code, no working app, no refund, and — this was the part that really stung — no contract. Nothing on paper that said what he had bought, when it was due, or what he was owed if it never arrived.

He did not lose money because he picked a bad developer. Plenty of good developers work in Noida and across Delhi-NCR. He lost money because he hired the way most small businesses hire: on trust, a UPI advance, and a few voice notes. When it went wrong, there was nothing to fall back on.

This post is about the boring paperwork that would have saved him. If you are about to hire an app developer in Noida — a freelancer, a small studio, or a full agency — the thing that protects you is not a gut feeling about the person. It is a clear, written agreement on five things, settled before your first payment: what exactly you are buying, how much and when you pay, who owns the app at the end, what happens if it is late or wrong, and where you stand if it all breaks down. None of this needs a lawyer's vocabulary or a 40-page document. It needs clarity, in writing, at the start — when you still hold all the cards.

I have built and shipped apps for fifteen years, and I run our app development studio in Noida. I have also cleaned up a lot of other people's messes. Almost every one of those messes traces back to something that was never written down. Let us make sure yours is.

Why the contract matters most on the cheapest apps

There is a strange rule I have noticed. The bigger the project, the more likely people are to insist on a contract. The smaller and cheaper it is, the more likely they are to skip one. This is exactly backwards.

A large company spending 20 lakh rupees on an app has a legal team and a procurement process; the paperwork happens automatically. A boutique owner or a clinic spending 30,000 rupees usually has neither, so a casual WhatsApp deal feels normal. But that boutique owner can least afford to lose the money, has the least leverage if things go wrong, and is the most likely to be dealing with an individual freelancer who could simply stop replying. The cheap app is where a contract earns its keep the most.

And a contract is not a sign of distrust. Think of it the way you think of a rent agreement or a GST invoice: not because you expect a fight, but because clarity now prevents a fight later. A written agreement protects the honest developer too — it tells them exactly what "done" means, so they are not chasing a target that keeps moving in your head. When I explain it that way, no reasonable developer objects. The ones who do object have just handed you the most useful piece of information you will get all project.

So before we get into the specific clauses, hold on to the one idea that runs through this entire post: decide everything before you pay, because your leverage is highest before the first rupee moves and vanishes the moment the final payment clears.

The five things your agreement must nail down

You do not need legal jargon. You need plain answers to five questions, written where both sides can see them. Here they are, and then we will go through each in detail.

1. Scope — exactly what you are paying for: which screens, which features, which platforms.
2. Payment — the total price, the taxes on top, and the milestones at which each part is paid.
3. Ownership — who owns the code, the accounts, the data and the copyright at the end.
4. Time and quality — the timeline, what "finished" means, and what happens if it slips or is broken.
5. Disputes — how you will settle a disagreement, and under which city's courts.

Get these five on paper and you have removed 90% of the ways an app project goes wrong. Let us take them one at a time.

Scope: the difference between "an app" and a fight

The most common cause of an app dispute is not dishonesty. It is two people who genuinely believed they had agreed to different things.

You pictured customer login, a product catalogue, online payment, order tracking, and an admin panel to manage it all. The developer heard "a shopping app" and priced a catalogue and a cart. Three weeks in, you ask where the order tracking is, and now you are arguing about whether it was ever included. Neither of you is lying. You just never wrote it down.

The fix is a short scope document — even a single page. List the screens and the features in plain English, and be specific about the fuzzy ones. Not "user accounts" but "customer can sign up with phone number and OTP, log in, and see their past orders." Not "payments" but "customer can pay by UPI and card through a payment gateway; the business receives the money directly into its own account." Write down the platforms too: Android only, or Android and iOS. And — just as important — write down what is not included, so a "small addition" later is understood by both sides to be extra work at an extra price.

If you want help turning a vague idea into a sharp, buildable list, a clear brief does most of this work for you, and I wrote a full guide on how to brief a developer or an AI so you get the app you actually pictured. The sharper your scope, the more accurate your quote, and the fewer arguments you will have later. Vagueness is not free; you pay for it in change requests, delays and bad blood.

Payment: never all up front, never all at the end

Here is where real money is won and lost, so read this section twice.

Two payment structures will hurt you, and they point in opposite directions. Paying 100% up front removes every incentive for the developer to finish on time, hand over properly, or fix the last irritating bugs — the money has already cleared, so the hard final 10% becomes optional for them. Paying 100% on delivery, on the other hand, is unfair to a genuine developer who has to fund weeks of work, and in practice it pushes them to rush and to present a take-it-or-leave-it result at the end, because they are desperate to get paid.

The healthy pattern sits in between: milestones tied to things you can actually see and check. Money and visible progress move together, in steps. For a small business app, a split like this works well:

The exact percentages can flex — some fair developers prefer a slightly larger advance, some projects have more stages — but the shape is what matters. A modest advance to start, chunks released against visible progress, and a meaningful final payment held back until a tested handover. That last 20% is your single strongest protection. A developer's willingness to fix the final problems and hand everything over cleanly depends almost entirely on money that has not yet been paid. Give it all away early and you have thrown away your leverage at exactly the moment you needed it.

A small booking advance is completely normal and fair — usually 20–30%. It reserves the developer's time and shows you are serious. But if someone you have never worked with insists on the full amount before any work is visible, treat it as a warning. At most, agree a tiny low-risk first stage — say, just the design — so you can judge how they work before you commit the rest.

The bill is bigger than the fee: GST, TDS and store accounts

When a developer quotes you "50,000 rupees for the app," that is rarely the number that leaves your account. Three extra items catch people out, and every one of them belongs in the written agreement.

GST — 18%. App and software development is a taxable service in India, taxed at 18% (it falls under the IT services category, SAC 998314, per the GST rate for IT services). So a 50,000-rupee build is 59,000 rupees on a proper invoice. Do not treat this as a nasty surprise — treat it as a reason to insist on a proper GST invoice. If your business is GST-registered, that 9,000 rupees of GST may be claimable as input tax credit, which softens the cost. And even if you cannot claim it, a real invoice is clean, dated proof of exactly what you paid for — the kind of document that settles an argument instantly. A developer who cannot or will not give you a GST invoice is either not registered (which is a fact worth knowing) or is asking you to transact in a way that leaves you no paper trail.

TDS — you may have to deduct it. This one surprises small business owners. If your total payments to a single developer or agency cross 50,000 rupees in a financial year, the tax rules generally expect you, the payer, to deduct tax at source and deposit it against their PAN. For professional or technical services this is commonly 10% under Section 194J; for a pure works contract it can be 1–2% under Section 194C. Which one applies depends on how the work is classified, so ask your accountant — the point here is simply to know it exists, build it into your paperwork, and not get a notice later for having ignored it.

Store fees — billed to you, by Apple and Google. To publish your app you need developer accounts, and these are charged by the platforms directly, not routed through your developer: a one-time US$25 registration for a Google Play developer account and US$99 a year for the Apple Developer Program. As I explain below, you want these accounts in your own name anyway — so budget for them as your cost, not a hidden extra the developer springs on you at launch.

Put all of this together and ask one simple question in writing: what is the all-in number — your fee plus GST, and which store fees will I pay directly? That one sentence stops the "50,000-rupee app" from quietly becoming 70,000.

Ownership: paying the bill does not make it yours

This is the clause people skip and regret the most, so I will be blunt: in India, paying for an app does not automatically make you its legal owner.

Under the Copyright Act, 1957, the author of the code — the person who actually wrote it — is its first owner. There is an exception for your own salaried employees, but an outside freelancer or agency is not your employee; the code they write stays theirs until they sign it over to you in writing. A paid invoice does not transfer copyright. A friendly relationship does not transfer copyright. Only a written assignment does.

So your agreement needs one plain line: on full payment, all source code, copyright and intellectual property in the app pass to me, worldwide and in perpetuity. And ownership is bigger than just the code — "the app" is really about seven separate things you need to control: the source code, the copyright, the Google Play account, the Apple account, the domain, the backend server and database (where your customer data lives), and every third-party account and API key (payments, SMS, maps, notifications). Losing any one of them can trap you just as badly as losing the code.

The cleanest protection is to own your own accounts from day one. Open the Google Play account (US$25, once) and the Apple account (US$99 a year) in your own name and business, then add your developer as an invited user. Now your app lives in your house and the developer is a helper you let in — the day you part ways, you simply remove their access and keep everything. The same goes for the domain, the backend and the payment gateway: in your name, not theirs.

Finally, make the handover the last milestone and tie your final payment to it — and then test it. The honest test is this: could a different developer, given only what you were handed, deploy a small update to your live app without ever contacting the first developer? If yes, you truly own your app. If no, you own a folder of files. I have written a complete guide on who really owns your app and its code, including the full seven-asset checklist and the exact store-account and signing-key traps — please read it before you sign anything, because ownership is the one mistake that is genuinely hard to undo after the fact.

Time, quality and what happens when things slip

Every app project runs into surprises, so a good agreement does not pretend nothing will go wrong — it says what happens when it does.

Write down a realistic timeline in stages, not a single "it'll be ready in a month." Tie it to the milestones: design by such-and-such, a testable build by such-and-such, launch after your testing. If you want to understand what is actually reasonable, I broke down how long it really takes to build an app in India — some slippage is normal and human; a build that is "almost done" for two months with nothing to show is not.

Two clauses are worth adding for your protection. First, an acceptance step: you get a working build to test against the agreed scope, and the final payment is due only after you confirm it does what was written down. This turns "is it finished?" from an argument into a checklist. Second, a plain line on delay: if the project slips badly past the agreed dates without good reason, you may pause payments or step away, keeping whatever has been delivered and paid for. You do not need harsh penalty language; you need a clear exit so you are never trapped funding a project that has quietly died.

Do not forget what happens after launch, either. An app is never truly "done" — phones update, stores change their rules, small things break. Agree up front what post-launch support looks like: is there a short free bug-fix window (say, 30 days) after handover, and what does ongoing maintenance cost after that? I explained the real numbers in what app upkeep costs after launch. Settling this in the contract stops the awkward situation where something breaks a week after launch and you are suddenly negotiating from scratch.

A worked example: two Noida cafes, same app, different endings

Let me make all of this concrete with a composite example, built from the kinds of cases I actually see across Noida and NCR. Two cafe owners, call them Rahul and Sana, each get the same app built: menu, table booking, online ordering, and a simple loyalty stamp card. Each pays a small studio around 80,000 rupees plus GST. Same app, same money. The endings could not be more different.

Rahul does it on trust. No scope document — "you know what a cafe app needs." He pays 50% up front and 50% on a vague "delivery," both over UPI, no GST invoice. The app is published in the studio's Google Play account. The customer database sits in a cloud account under the studio's email. Fourteen months later, Rahul wants to add a festival menu and switch to a developer closer to home. Now the trouble surfaces: the studio owns the store listing, holds the customer data, and is slow to help with a transfer they are under no written obligation to do. Rahul cannot even prove precisely what he originally paid for. Getting his own customer list back becomes a negotiation. He spends two stressful months and extra money untangling an app he thought he owned outright.

Sana does it on paper. One page, agreed before she paid a rupee. It named the exact screens and features, the all-in price with 18% GST, and a 20 / 30 / 30 / 20 milestone split. It said the code and copyright become hers on final payment, and that the Play Store account, the Apple account and the payment gateway would be opened in her name, with the studio added as a user. Handover was the final milestone, tied to her last payment, and she held that 20% until a second person confirmed the app could be updated using only what she had received. When she later wanted her festival menu and a new developer, there was no drama at all: she removed the old studio's access, added the new developer, handed over the account logins and a short document, and shipped the update in a fortnight.

The entire gap between Rahul and Sana is a single page, agreed in the first week when they both held full leverage, versus decisions avoided until the last week when one of them held none. That is this whole article in one story.

The local advantage: why hiring in Noida can work in your favour

Most app work today happens online and over WhatsApp, and that is fine — you do not need your developer in the next building. But when you do hire locally in Noida or Delhi-NCR, three quiet advantages are worth using on purpose.

You can meet for the parts that matter. You do not need daily meetings, but a face-to-face kickoff, a design sign-off, and a handover session are far richer in person than over chat. For a first app, that human contact also tells you a lot about who you are dealing with.

Same hours, same language, same context. A local developer understands UPI-first customers, WhatsApp-led support, GST invoicing and the way NCR businesses actually run. You are not explaining your world from scratch, and you are not waiting overnight for replies across a time zone.

Disputes stay near home. This is the one people forget. Your agreement should include a plain line on jurisdiction — which city's courts govern the contract if it ever comes to that. If you and your developer are both in Noida, naming the courts of Gautam Buddh Nagar (the district Noida sits in) keeps any formal dispute local and cheaper for you, instead of forcing you to chase a matter in another state. You will almost certainly never need it. But it costs one sentence to add, and it quietly tilts the playing field back towards you.

There is one more local point worth knowing, and it cuts both ways. If your developer is a registered MSME (a micro or small enterprise), the law actively encourages you to pay them on time. Under the MSMED Act, 2006, buyers are expected to pay registered micro and small suppliers within the agreed period, up to a maximum of 45 days, and unpaid suppliers can escalate through the government's MSME Samadhaan system. On top of that, income-tax rule Section 43B(h), introduced in 2023, means that if you delay paying a registered MSME supplier beyond that limit and it is still unpaid at year-end, you can lose the tax deduction on that expense for the year. In plain terms: paying your developer promptly is not just good manners — it can be good tax sense. Good contracts and prompt payment protect both sides, and the businesses that treat their developers fairly are the ones who keep a good developer's phone number for the next project.

Your one-page hiring checklist

You do not need to memorise this article. You need this checklist in front of you before you pay anyone. Walk through it with the developer or studio you are about to hire, and watch how they respond — their comfort with these questions tells you almost everything.

• Scope in writing: every screen and feature listed in plain English, platforms named, and what is not included spelled out.
• All-in price: the fee, plus 18% GST, plus which store fees (US$25 Google, US$99/yr Apple) you will pay directly. One clear number.
• Milestone payments: a modest advance, chunks released against visible progress, and a meaningful final payment held back until a tested handover. Never 100% up front.
• A proper GST invoice for every payment.
• Ownership clause: on full payment, all code, copyright and IP become yours, worldwide and forever.
• Accounts in your name: Google Play, Apple, domain, backend, database and payment gateway opened in your name or transferred to you; the developer gets access as an invited user.
• Tested handover as the final milestone: the code, the signing keys, every login, and a short plain-English document explaining how it all fits — with a check that a new developer could actually update the app from it.
• Timeline and acceptance: staged dates, a test-and-approve step before final payment, and a clear exit if the project stalls badly.
• Post-launch: a short free bug-fix window, and the cost of maintenance after that, agreed now.
• Disputes and jurisdiction: how disagreements are settled, and the courts (e.g. Gautam Buddh Nagar for Noida) that govern the contract.

If you are still weighing up a freelancer versus a studio versus an agency, I compared the honest costs and risks of each in app developer vs agency vs freelancer, and I listed the nine questions to ask before you hire any app company. Read those alongside this one and you will hire from a position of real knowledge, not hope.

The honest trade-off: match the paperwork to the stakes

I will end with the same honesty I ask of any developer. You do not need a lawyer and a fifteen-clause contract for every tiny app. Match the formality to the stakes.

A cheap first app you are only testing for a few weeks can run on a clear one-page email agreement — scope, price, milestones, ownership, done. A business you are staking your livelihood on deserves more: a proper signed agreement, your own accounts from day one, and, if real money is involved, a lawyer to read it before you sign. The mistake is never "I kept it simple." The mistake is never deciding — drifting along on good vibes and a UPI advance, and discovering the answers to all five questions only on the day the good vibes end.

That cloud-kitchen owner who called me last month? He is fine now. We rebuilt his app the right way — his scope, his milestones, his accounts, his code, all in writing from day one. The rebuild cost him a little more than the money he lost. What it bought him was the certainty that it can never happen again, because now, on paper, he owns his app and controls every lever that runs it.

If you would rather hire the right way from the start — fixed pricing agreed up front, milestone payments, and full ownership of your code and accounts in writing — that is exactly how we work at our app development studio in Noida. And if you just want to see honest, transparent numbers before you talk to anyone, our fixed app pricing is all there in the open. You should own your business. Your app is your business. Hire in a way that keeps it that way.