How to choose an app development company in India: 9 questions to ask before you pay

Choosing who builds your app is a bigger decision than most people realise when they start. You are not buying a finished product off a shelf. You are handing over money, months of time and your business idea to a company you have often known for a week, and trusting them to turn it into something real. Get that choice right and you end up with an app you own, that works, delivered close to on time. Get it wrong and you can lose the whole fee, half a year of calendar time, and then have to pay a second company to clean up the mess — while your business stands still.

So this post is about the part everyone rushes: how to choose an app development company in India without getting burned. I am going to give you the nine questions I would ask any company before paying them a rupee, the answers that should reassure you and the ones that should worry you, the red flags that mean walk away, and a simple scorecard to compare your options. This is written for the owner of a shop, a clinic, a coaching institute or a D2C brand — someone smart and busy who is not technical and does not want to be. You do not need to understand code to choose well. You need to know what to ask.

First, where do you even find companies to consider?

Before the questions, a word on where good candidates come from, because the source shapes the shortlist.

A referral from someone who actually shipped an app is the strongest lead you can get. If a business owner you know had a good experience — got their app built, owns it, and would use the company again — that is worth more than any advertisement. Ask around your own network first.

Independent review directories are the next best thing. Platforms like Clutch and GoodFirms list development companies with client reviews, and both do at least some verification of who is reviewing. Clutch, for instance, ties reviews to a reviewer's LinkedIn, Google or company email and labels a review "Not Verified" if it cannot confirm the reviewer's identity or the project — so a verified review carries real weight. Use these directories as a place to build a shortlist and to read what past clients say, not as a final verdict.

But use them with your eyes open. Companies can pay for prominent placement in these directories, so the ones at the top are not necessarily the best — they are often the ones who paid to be seen. And read the reviews properly: a wall of identical five-star reviews with no specifics is a warning sign, not reassurance. Real client reviews mention real details — what was built, what went wrong, how the team handled it. Go looking for the three-star reviews and read those most carefully. They tell you how a company behaves when something is hard.

A plain Google search for "app development company" plus your city will work too, but remember that ranking on Google mostly reflects marketing budget, not build quality. Everything on that first page still has to pass the same nine questions below.

Aim to shortlist about three companies. One gives you nothing to compare. Ten is a full-time job you do not have. Three lets you compare prices, spot an outlier, and still do the real checking on each.

Question 1: Can I see apps you built that are live right now — and use them?

This is the first filter and it removes a surprising number of companies. Ask for two or three apps they have actually built that are live on the Play Store or App Store today. Then do the thing most people skip: download them and use them. Tap around. Try to place an order or make a booking. See if it feels fast and finished or slow and broken.

Screenshots in a portfolio prove nothing — anyone can design a screen that will never work. A live app you can hold in your hand proves the company can take something all the way from idea to a real listing that Apple and Google approved. If a company cannot show you a single live app and only has "designs" and "prototypes", that is a serious gap. You do not want to be their first real launch.

While you are at it, notice whether the apps they show you are anything like yours. A company that has shipped ten small-business shopping and booking apps understands your problems far better than one whose portfolio is all big-corporate dashboards.

Question 2: Who exactly will build my app — your team, or someone you outsource to?

This question catches the middleman. Some "companies" are really just a salesperson and a website; they take your money and quietly hand the actual work to unknown freelancers they have never met, sometimes in another country, often at a fraction of what you paid. When something goes wrong — and something always goes wrong at some point — nobody is truly responsible, and you cannot get a straight answer because the person you are talking to is not the person building.

So ask plainly: who will write the code? Is it your own in-house team or is it outsourced? If it is outsourced, to whom, and who is accountable to me? A good company answers this openly. It is completely fine for a small studio to have a tight in-house team, and it is even fine for some specialised work to be done by trusted partners — as long as it is transparent and one company remains clearly responsible to you. What is not fine is a company that gets evasive about who actually does the work.

Question 3: What is your price — and is it fixed, or does the meter run?

Money is where most misunderstandings live, so get it fully into the open before anything starts.

First, understand the two ways companies charge. A fixed price means one agreed number for an agreed scope — if the work takes longer than expected, that is the company's problem, not yours. Charging by the hour (often called time-and-materials) means you pay for the time actually spent, so the final bill is not knowable up front. For most first-time owners with a reasonably clear idea, a fixed price is safer, because it moves the risk of overruns onto the company. Hourly billing makes sense mainly for genuinely exploratory projects where nobody can say up front what the finished app looks like. Some companies sensibly offer a short paid discovery or blueprint phase to nail down the scope, then a fixed price for the build itself.

Second, make the quote spell out exactly what is and is not included. Two quotes for "an app" can differ by lakhs simply because one quietly includes an admin panel, payments, and separate iOS and Android work while the other does not. Force each company to list the features line by line so you are comparing the same thing.

Third, ask about the costs that live outside the build price, because a quote that hides them only looks cheaper:

• 18% GST is added to app development services in India. A "₹25,000" quote is really about ₹29,500 out of your pocket. Ask whether the number you have been given includes GST or not.
• Store fees, billed to you directly by the platforms: Google Play charges a one-time registration of about $25, and Apple charges about $99 a year for its Developer Program.
• Payment gateway fees if your app takes money — roughly 2% plus GST on that fee for cards, while plain UPI is effectively free to you at the time of writing.
• Ongoing upkeep after launch (its own question below).

A company that walks you through all of this without being pushed is being honest. One that shows only the headline build price and goes quiet on the rest is not cheaper — it is just less complete. If you want to see what a clear, itemised, fixed price looks like in practice, our app pricing page lays out exactly what each tier includes.

Question 4: Native, cross-platform or no-code — and why for my app?

You do not need to become a technical expert here. You just need the company to explain their choice in plain words and to have a reason beyond "it's what we always do".

In simple terms: native means building your app separately for Android and iPhone, which is powerful but roughly doubles the work; cross-platform (tools like Flutter) means one set of code produces both the Android and the iPhone app, which for most business apps cuts the time and cost meaningfully without the user ever noticing a difference; and no-code means assembling an app from ready-made blocks, which is fast and cheap but hits limits as your needs grow.

The right answer depends on your app, and the point of the question is to hear the reasoning. A company that says "we will build yours in Flutter because it gives you both platforms from one codebase and keeps your cost and timeline down, and your app does not need anything native-only" is thinking about you. A company that cannot explain the choice, or pushes the most expensive option without a reason, is not. If you want to understand the trade-off before the call, my guide on no-code versus custom apps breaks down which path suits which kind of business.

Ask the reasoning question about the choice of approach early, because the approach is one of the most expensive things to change after the build has started — fixing a wrong architecture decision halfway through is far costlier than getting the choice right on day one.

Question 5: Who owns the app, the code and the accounts when it is done?

This is the question that protects your business, and almost nobody asks it until it is too late.

Here is the part that surprises people: under India's Copyright Act, 1957, the person who writes the code is its first owner by default — not you, the person who paid — unless the code is assigned to you in writing or was written by your own salaried employee. So a warm "don't worry, the app is yours" over WhatsApp means nothing on its own. Ownership has to be written down.

Your contract must clearly transfer, to your name and on final payment:

• The source code and the design files — the actual app, not just a copy you can run.
• The Google Play Console and Apple Developer accounts, or at minimum the app published under accounts you control.
• The backend and database where your app's data lives.
• The domain name and any web addresses.
• The app signing keys — the digital keys without which nobody, including you, can update the app on the stores.

If any of these stays in the company's name, you do not fully own your app — you are renting it from them, and you can be locked out or held to ransom for updates. I have seen owners discover, a year after launch, that they could not push a simple update because the signing key and the Play account belonged to a developer who had stopped replying. Do not let that be you. The full checklist and the traps live in my detailed guide on who owns your app and how the handover works in India. Ask this question, get the answers in writing, and how a company responds will tell you a great deal about everything else.

Question 6: What happens after launch — who fixes it, and what does it cost?

An app is not a painting you hang on a wall and forget. It is more like a car: it needs servicing, and things break if nobody maintains it. Phones update, Android and iOS release new versions, and an app that worked perfectly at launch can start crashing months later through no fault of yours. The most painful surprise for a first-time owner is finding out, after go-live, that support was never included and the company that built the app has quietly moved on.

So pin this down before you sign, not after. Ask:

• After launch, how long are bug fixes free? (A fair answer is usually a warranty window of some weeks or months for defects.)
• How fast will you respond if the app breaks — same day, same week?
• After the free window, what does ongoing care cost per month, and what does it cover?

Ongoing upkeep is a normal, real cost — care plans commonly start in the region of a few hundred rupees a month for basic uptime help and small fixes and rise with how much change you want. That is not a company being greedy; it is the honest cost of keeping software alive. On larger custom builds the rough industry rule is that maintenance runs 15 to 20% of the build cost a year. What matters is that the company talks about it openly. A company that plans to support you will happily explain its care plans; one that plans to disappear gets vague. I wrote a whole piece on what app maintenance really costs after launch if you want the full picture before you ask.

Question 7: How will we stay in touch, and who is my one point of contact?

Communication problems sink more projects than technical problems do. If, during the polite sales stage, replies are already slow and vague and you are being passed between people, it will only get worse once they have your deposit and the hard part begins.

Ask how the project will be run day to day. Will you have one named person — a project manager or the founder — who is your single point of contact? How often will you get updates, and in what form? Can you see progress as it is built, or do you just wait in the dark and hope? The good answer is a clear rhythm: one contact, regular updates, and something you can see or test at each stage. The bad answer is you emailing individual developers, chasing status across three apps, and getting different answers from different people. That chaos is a preview of the whole project.

You are not being demanding by asking this. You are checking whether the company treats your build as a managed project or a loose favour.

Question 8: What do you need from me, and what if I change my mind mid-build?

This question reveals whether a company actually understands why app projects fail — and the honest data here is worth knowing. Across decades of the well-known Standish Group "CHAOS" research into software projects, only about one in six projects in the original study came in on time and on budget, and nearly a third were cancelled before they finished. The leading causes were not bad programmers. They were things like unclear requirements, not enough input from the customer, and requirements that kept changing — together a huge share of the failures. The same research found small, tightly-scoped projects succeed far more often than big sprawling ones.

Read that twice, because it flips the usual worry. The biggest risk to your app is not that the company codes badly — it is fuzzy scope and mid-build changes. So a good company will tell you clearly what it needs from you (your content, your product data, your logo, quick decisions) and will have a calm, written process for handling changes: change requests are noted, priced, and agreed before they are built, so a "small addition" does not silently blow up your timeline and budget. A company that says "sure, we'll add anything anytime, no problem" is not being generous; it is setting up the exact chaos the research warns about.

Your side of this is to come in with a clear brief. The sharper your brief, the better and cheaper your app — I put together a simple one-page way to brief a developer or an AI that removes most of the guesswork. If you want the fuller picture of how apps go wrong, why most first apps fail covers the boring things that quietly prevent it.

Question 9: What exactly is in the written contract?

Everything above only counts if it is written down. A friendly conversation is not a contract, and memories differ conveniently once money is involved. Before you pay anything, insist on a written agreement, and make sure it covers, at minimum:

• Scope — exactly what is being built, and just as importantly, what is not.
• Price and type — the total, whether it is fixed or hourly, and what counts as a chargeable extra.
• Payment schedule — tied to milestones (for example, on design sign-off, on a working build, on final delivery), never one big lump before anything exists. Never pay the full amount before you have the finished app and the accounts in your name.
• Timeline — real dates and stages, not "a few weeks".
• Ownership — the assignment of code, design files and all accounts to you on final payment (see Question 5).
• Support — what post-launch help is included and for how long (see Question 6).
• Exit clause — what happens, and who gets what, if either side wants to stop partway.

A good company wants a clear contract as much as you do, because it protects them too. If a company resists putting these basics on paper and pushes you to just "trust them and start", that resistance is your answer. The contract is not paperwork to rush past — it is the whole deal.

Red flags that should make you walk away

Some signals are strong enough that, on their own, they justify ending the conversation. Watch for these:

• An instant, confident, flat quote with no questions asked. If a company reads a two-line brief and sends a fixed price within the hour without asking about your business, your customers, your features or your data, they are guessing — and you will pay for the guess later. The companies worth hiring ask you more questions than you ask them.
• A price far below everyone else's. If two quotes cluster around a number and one comes in 50 to 70% lower, that is a question, not a bargain. Ask what is missing, who really does the work, and whether the deposit is the last you will see of them.
• No live apps you can download and use. Only mockups and promises means you would be their experiment.
• Vagueness about ownership or accounts. Any hesitation on Question 5 is a serious warning.
• No written contract, or pressure to pay most of the money up front. Both put all the risk on you.
• Slow, evasive communication before you have even paid. It never improves after the deposit clears.
• A flood of flawless five-star reviews with no specifics. Real work produces detailed, mixed feedback. Perfect and vague usually means bought.

None of these guarantees a company is dishonest. But each one is a reason to slow down and dig, and two or more together is usually a reason to move on.

A worked example: scoring three shortlisted companies

Let me make this concrete. Say you run a mid-sized salon chain and you want a booking app. You do the sensible thing and shortlist three companies. Here is how a simple scorecard turns a confusing set of sales calls into a clear decision. Score each company from 1 to 5 on the things that actually matter, using the nine questions.

Look at what the scorecard reveals. Company B is the cheapest by a wide margin, and on price alone it wins — which is exactly the trap. But it has no verifiable live apps, would not commit ownership to writing, was vague about support, and refused a proper contract. That ₹14,000 is not a deal; it is the setup for a half-built app you do not own and cannot get updated. Company C is excellent and scores well, but it is the priciest, and much of what it offers beyond Company A is capacity your salon booking app does not need yet. Company A is the right choice: strong evidence on every question that protects you, a fair fixed price with GST and extras out in the open, and a clean contract. It is not the cheapest number, but it is the lowest real risk — and on a purchase like this, lowest real risk is what you are actually shopping for.

The scorecard also does something quietly powerful: it stops you from being swayed by the salesperson you liked most or the number that was lowest, and forces you to decide on evidence you can check. Fill one in for your own shortlist. It takes an afternoon and it is the best afternoon you will spend on the whole project.

Your one-page checklist before you pay

Pull it all together into something you can keep on your phone and use on any company you are considering:

1. Live apps — did they show me two or three real apps I could download and use? (No live apps, no deal.)
2. Who builds it — is it their own team, or is work quietly outsourced to people I cannot see?
3. Price — is it a clear fixed price with GST, store fees and gateway fees all spelled out, or a vague headline number?
4. Approach — did they explain, in plain words, why they are building it the way they are?
5. Ownership — will the code, design files and all accounts transfer to my name in writing on final payment?
6. After launch — is support explained, with a warranty window and a clear care-plan cost?
7. Communication — do I have one named contact and a promised update rhythm?
8. My part and changes — did they tell me what they need from me and how changes are priced?
9. Contract — will they put scope, price, timeline, ownership, support and an exit clause in writing?

If a company scores well on these nine, you have found a partner. If it stumbles on the ones that protect you — ownership, contract, support — keep looking, however much you liked the sales call or the price.

The bottom line

Choosing an app development company is not about finding the cheapest quote or the smoothest talker. It is about finding the company that gives you the best evidence it will actually deliver, actually support you, and actually hand you an app you own. The nine questions in this post are simply a way to move the decision off gut feeling and onto things you can check: live apps, real references, honest pricing, written ownership, and a clear contract. Ask them, write the answers down, and the right choice usually makes itself obvious.

At Roy Digital App Studio we have tried to make being the easy company to say yes to the whole point — fixed prices with nothing hidden, apps you own outright, and everything in writing; you can see how our app studio works and what we build and judge us against these same nine questions. If you would rather have a clear number for your own idea before you talk to anyone, our fixed app pricing shows exactly what each tier includes. And if you want to understand every quote from the inside — to know what good looks like because you have built one yourself — that hands-on skill is the whole point of our no-code app building course. Whichever path you take, do the vetting first. The week you spend asking these questions is the cheapest protection you will ever buy on the most important business decision you are about to make.