Questions to Ask App Developers
Twenty questions for a first conversation with an agency or freelance developer about building a mobile or web app, covering scope, who does the work, ownership, and what happens after launch. Written for a non-technical buyer.
The questions
Open any question for the note
Can you walk me through a project like mine from the first call to launch?
Why ask it
An open opening that shows how they organise work without asking them to sell. Listen for whether they mention a discovery phase, when the client sees something running, and what stage they say the money is spent. Firms that jump straight to design usually skip requirements.
What would you need from me before you could quote this properly?
Why ask it
A developer who can price your app off a one-page description is guessing, and the guess will be low. The list they ask for, user flows, existing data, integrations, admin needs, tells you how carefully they scope work.
Looking at what I have described, what would you cut from the first version?
Why ask it
Tests whether they will disagree with a paying customer. Anyone who says the whole list sounds great is optimising for the contract. A useful answer names two features and gives a reason: cost, risk, or the fact that you do not yet know if users want them.
For this app specifically, would you build native or cross-platform, and why?
Why ask it
Watch for a reason grounded in your app rather than in their skills. Heavy camera, background, or offline use pushes toward native, and a shop with only one specialism will recommend that specialism regardless of the answer.
Who will actually write the code, and are they your employees or subcontracted?
Why ask it
Sales and delivery are often different people, and some firms resell work to another firm entirely. It is not automatically a problem, but you should know how many organisations sit between you and the keyboard, and which time zone they are in.
How many other projects will those people be working on at the same time?
Why ask it
The honest answer is rarely one. What matters is whether you are getting a fraction of several people or the focused attention of a small team, because a developer split across four clients loses a day a week to context switching.
How often will I see the app running, and on what device?
Why ask it
Weekly builds on your own phone are the only real protection against a project drifting for two months. Screenshots and status reports can look healthy while nothing works end to end.
What gets tested automatically, and what does a person check by hand?
Why ask it
Nobody says they do not test. Ask which parts have automated coverage and you learn whether a change late in the project can break something early in it without anyone noticing until you do.
The first time we disagree about whether something is a bug or a new request, how does that get settled?
Why ask it
This argument happens on every project, and the answer reveals whether there is a written specification to point at. Firms that say it rarely comes up have either never had a hard client or are about to bill you for their own misunderstandings.
How do you estimate, and what happens when an estimate turns out to be wrong?
Why ask it
Fixed price, time and materials, and capped time each shift risk somewhere different. What you want to hear is who absorbs an overrun and at what point you find out about it: at fifty percent of the budget, or after it is gone.
What would you build here, and what would you buy from an existing service?
Why ask it
Payments, authentication, push notifications, and search are usually cheaper and safer to buy. A developer who wants to build all of it is either padding hours or unaware of the maintenance burden they are handing you.
How will you handle user accounts, personal data, and anything that has rules attached to it?
Why ask it
If your app touches health, children, payments, or European users, there are obligations that shape the architecture rather than being added later. A developer who has dealt with this will ask you questions back instead of reassuring you.
At what point in the process does accessibility get checked, and by whom?
Why ask it
Answers that treat it as a final pass mean it will not happen. Look for mention of contrast, text sizing, screen reader labels, and touch target size as part of design, not as a bug list at the end.
Who owns the code, the design files, the app store listings, and the domain when we are done?
Why ask it
Ask about each item separately, because ownership often differs between them. Accounts registered in the agency's name are the common trap: it can leave you unable to publish an update without their cooperation.
If we stopped working together next month, what would I be left holding?
Why ask it
The concrete version of the ownership question. A good answer describes a repository you can access, documented setup steps, infrastructure in your accounts, and credentials in your possession. A vague answer means a costly handover.
What is involved in getting this into the app stores, and who deals with a rejection?
Why ask it
Review rejections are routine and can add weeks. You want to know whether resubmission is inside the price, who writes the privacy disclosures, and whose developer accounts the app is published under.
After launch, what tends to break, and what does keeping it running cost per month?
Why ask it
Every app has running costs: hosting, third-party services, store fees, and someone's time. A developer who has supported their own work will quote a monthly range and describe what a typical month of small fixes looks like.
When Apple or Google ships an update that breaks something, how does that get handled?
Why ask it
This happens at least once a year and is not covered by a bug warranty, since nothing was wrong when it shipped. Find out whether it falls under a support agreement or becomes a new quote each time.
Can I speak to a client whose project did not go smoothly?
Why ask it
Anyone can supply a happy reference. Asking for a difficult one tells you whether they can talk about a project that ran over or a relationship that ended, and how they describe their own part in it. A flat refusal is itself informative.
In your experience, what is the most likely reason a project like this fails?
Why ask it
The best answers usually implicate the client: unclear decisions, a slow approver, changing requirements, no one to supply content. A developer who blames only technology, or claims none of their projects fail, has not thought about it or will not say.
Buying Software Well
Practical guidance for the conversation itself
Before You Sign Anything
Pay for a Small Piece First
A short paid discovery phase, or one narrow feature built end to end, tells you more than any interview. You learn how they communicate, how they estimate, and what their code looks like, for a fraction of the full budget and without a long contract.
Have Someone Technical Read the Proposal
You do not need to understand the stack, but an independent developer can spot a proposal with no testing, no hosting plan, and no handover in twenty minutes. An hour of their time is the cheapest insurance in the process.
Register the Accounts Yourself
Create the app store, cloud, domain, and analytics accounts in your own name and invite the developer in. This one habit removes most handover disputes before they exist, and it costs nothing at the start of a project.
Name a Single Decision Maker on Your Side
Projects stall on client-side approvals more often than on code. Decide in advance who answers questions within a day, and tell the developer who that is, because ambiguity on your side is billed at their hourly rate.
What the Answers Tend to Reveal
- Asking questions back about your users and your data is the strongest positive signal in a first call.
- A quote produced without a written scope is a sales number, not an estimate, and it will be revised upward.
- Reluctance to name the individuals doing the work usually means the work is being subcontracted.
- No mention of who maintains the app after launch means nobody has planned for it, including you.
- A portfolio of apps no longer in the stores is worth asking about directly: it may mean short-lived clients or abandoned handovers.
Where These Projects Go Wrong
Choosing on Price Alone
The cheapest bid usually assumes the simplest reading of your requirements. When reality intervenes, the difference arrives as change requests, and the total lands above the mid-priced quote you rejected.
Building the Whole Thing Before Anyone Uses It
A six-month build with no users is six months of unverified assumptions. Insist on something real in front of a handful of actual users early, even if it is embarrassing, because that feedback changes the remaining scope.
Leaving Ownership to the Contract's Final Page
Code, designs, and accounts are separate assets and are often treated differently. Settle all three in writing before work starts, when you still have leverage.
No Plan for Month Thirteen
Apps need updates for new operating systems whether or not you are adding features. If nobody is on the hook for that, the app quietly stops working within about two years.