Between 2023 and 2026, GitClear analysed 623 million changed lines of code and found the work itself changing shape. Duplicated blocks are up 81% on 2023, while refactoring moves, the signal that somebody tidied up after themselves, are down 70%. In the first half of 2026 a developer was roughly five times more likely to paste code than to restructure it. None of that shows up in a demo. The app opens, the buttons respond, and the expensive part stays invisible for a year. That is the awkward part of hiring an app developer in 2026: the output all looks the same now.
Working software used to be the filter. Anyone can produce something that runs by Friday, so a prototype no longer separates the people who finish from the people who stall at 80%. What still separates them is how they answer questions about the parts you will never see: who reads the code, what happens when you change your mind, who pays when it breaks at midnight. Below are ten questions worth asking before hiring an app developer, whether that turns out to be one freelancer or a dedicated development team. Ask all ten in a single call and you will learn more than any portfolio review can tell you, since a portfolio shows the one project that went well.
Questions about who will actually build the app
The person on the sales call is rarely the person who writes your code. Hiring an app developer usually means buying one or two people rather than a department, so a single substitution changes the whole engagement. Start there.
1. Who from your team will still be here in six months?
A typical app build runs on one or two developers plus a designer and someone who tests. One person leaving takes half your engineering capacity and most of the accumulated context with them. On a fifty-person enterprise programme that is a staffing inconvenience. On yours it is a restart.
Ask how long those people have worked together, since a pair who have shipped three apps side by side recover from a departure far better than two strangers assigned last month. Then ask the question that produces an honest answer: what happened the last time somebody rotated off a build halfway through, and how long the replacement took to become useful.
A good answer names individuals and describes the cover standing behind each of them: a designated backup developer who already holds access to the code and the environments, rather than someone introduced to both during an emergency. Ask how much notice you get for planned absence, since three working days is a reasonable floor and the answer reveals whether anybody has thought about it at all.
A worrying answer talks about resources and capacity. An app development company that describes people as interchangeable tends to treat them that way, and you find out in week three, when the developer who understood your payment flow is on somebody else’s project.
2. How much of my code will an AI write, and who reads it before it ships?
Every serious developer uses AI now, so a yes-or-no version of this question wastes it. DORA's 2025 study of nearly 5,000 technology professionals put adoption at 90%, with 30% reporting little or no trust in what the tools produce. The useful part covers what happens in the minutes after the model writes something.
Andrej Karpathy, who coined the term vibe coding in early 2025, drew that line himself a year later: vibe coding means nobody reads the generated code, while agentic engineering means a human checks every step. Ask which of the two you are being sold. We set out where the boundary sits and why it keeps moving separately.
The gap between them is measurable. CodeRabbit reviewed 470 pull requests and found the AI co-authored ones carried 1.7 times more major issues and 2.74 times the security vulnerability rate of human-written code. A benchmark paper, Is Vibe Coding Safe?, found 61% of a leading agent's solutions functionally correct and only 10.5% secure. Adding security hints to the prompt did not close the gap.
What you want back is a description of review, and the bar is plain enough to write into a contract: no change reaches production without a code review by a second developer. That is the rule we work to at Fingoweb, and it holds regardless of who or what produced the first draft. Around it sit the ordinary supports: dependency and static analysis running in the pipeline, and a list of places AI never goes unsupervised, which normally means authentication, payments and anything touching personal data. Our breakdown of what AI builders leave open covers the failures that get through when nobody looks.
Two answers should slow you down. "We don't use AI" is almost certainly untrue, which tells you they will hide it. "AI writes most of it now, we're much faster" with no review attached tells you the app will look finished long before anyone has read it. We spend a fair amount of time cleaning up vibe-coded projects, and the pattern repeats: it worked perfectly on the day it was handed over.
3. Which part of my app have you never built before?
Most of an app is screens and API calls. Almost every app also has one component that is genuinely harder than the rest: offline sync that survives a lost connection, real-time updates, background location, in-app purchases with server-side receipt validation, Bluetooth hardware, a video pipeline. Name your hard part out loud and ask whether they have shipped it in production, for someone else.
The answer you are listening for contains a number. How long the last one took, and what surprised them. Someone who has done it will also tell you which part they would attack first, unprompted.
A flat "we've done everything" means one of two things, and both cost you the same. Either they did not listen to the hard part, or they are planning to learn it on your invoice.
Questions about how the work will run once it starts
Delivery problems announce themselves early, in the rhythm of the first month, and almost never in the contract. These three questions describe what your Tuesdays are going to look like.
4. How often will I see something I can open?
Hold people to a build you can run yourself: TestFlight for iOS, internal testing on Google Play, a staging link for anything web-facing. Two weeks is the working floor, since that is the rhythm most teams already run on, and the better ones put something in front of you sooner whenever the work allows it. Ask which week the first installable version lands, and treat anything past week four as a warning.
Listen for one piece of honesty here. Some fortnights produce nothing a client can see, because the work went into a data migration, an integration or a rebuilt backend, and a team that tells you so plainly is worth more than one that manufactures a demo to fill the slot. What you want is a straight account of where the effort went, which is the other half of the answer: a weekly record of tasks with hours against each, taken from whatever time tracker the team already fills in.
The pattern to avoid is an app development company that defers everything to a milestone. Monthly cycles with a demo at the end give you one chance every four weeks to notice the project has drifted, and drift compounds in between.
5. What happens when I change my mind in week six?
You will change your mind. Everyone does, usually once real screens exist and the idea becomes concrete. What matters is whether the company has a mechanism for it or just a temperament.
Under time and materials, a change is absorbed into the flow of work and the budget moves. Under fixed price, the same change becomes a change request with its own estimate, approval and schedule impact. Both are workable, and the failure mode is a vendor who has never thought about which one they are running. Writing a scope that survives contact with an opinion is its own discipline, which we unpacked when looking at planning and budgeting a software project.
A good answer describes machinery: how a change gets estimated, who approves it before anyone starts, which items are too small to bother estimating, and at what point they will tell you the budget is running out. That last commitment matters most, because a warning at 70% spent leaves you choices and a warning at 100% does not.
A worrying answer is "we're flexible, no problem". Flexibility without a process is how you end up with an invoice nobody predicted.
6. What do you need from me, and how quickly?
Ask this one and watch the reaction, because almost nobody asks it and it flushes out whether the person opposite has run a real project. App builds stall on the client side at least as often as on the developer side.
The list is longer than people expect. Brand assets, legal texts for your privacy policy and terms, API credentials for whatever you already run, content for empty states, a decision on which platform launches first, access to your own developer accounts. Each item that arrives late moves the date.
You want a written list with dates attached and a plain statement of what happens when something slips. Be wary of "nothing, we'll handle everything". Nobody else can write your terms of service, and a company that pretends otherwise intends to bill you for the discovery later.
Quality questions to ask before hiring an app developer
Apple reviewed 7,771,599 submissions in 2024 and rejected 1,931,400 of them, according to its own App Store Transparency Report. Performance was the single largest rejection category at 1,235,471 submissions, which describes a testing failure rather than a disagreement about design. Two questions cover the ground.
7. How will this be tested, and on which devices?
The answer you want contains actual hardware. A four-year-old mid-range Android handset with a weak signal. The smallest screen you plan to support. A tablet, if tablets are in scope. Simulators are honest about layout and silent about everything that makes real phones difficult: thermal throttling, aggressive battery management, a carrier that drops the connection halfway through an upload.
Then ask who does the testing. A dedicated tester and a developer checking their own work are different products at different prices, and a company with nobody in the first role will usually admit it when asked plainly.
A good answer names devices, names a person, and identifies which flows get automated tests. Payments, authentication and anything that syncs data belong in that set, because those are the paths where a silent failure costs money rather than goodwill.
A worrying answer treats QA as a phase at the end. Testing compressed into the last week is the line item that gets cut when the build runs late, and it always runs late.
8. How will I know the app is broken before my users tell me?
Mobile apps fail quietly. A crash that only happens on one manufacturer's Android build, a certificate that expires on a Saturday, a backend timeout that turns into a spinner nobody explains. Almost nobody files a support ticket about any of it. They uninstall, and your analytics show a number going down with no reason attached.
Four things belong in the plan before launch rather than after the first incident:
- Crash reporting wired into the release build, with symbols uploaded so the reports are readable.
- Uptime and error-rate monitoring on the backend the app depends on.
- A named person who receives the alert. Not a shared inbox.
- A rollback path, because store review adds days to any fix you push through the front door.
Then pin down what happens once an alert fires. A support arrangement worth signing sorts incidents by severity and attaches a clock to each level. Our own commits to acknowledging a critical failure within three hours between 8am and 8pm on working days, and to a workaround inside three working days for serious faults that stop short of taking the system down. Numbers like those are negotiable, and their absence is the problem.
Anyone who suggests you will hear about problems through App Store reviews has answered a different question. By the time a one-star review explains your bug, the users who hit it first have already gone.
Questions about the months after launch
The build takes a few months. Owning the app takes years, and hiring an app developer settles the terms for those years during the same conversation, usually with far less attention paid to them.
9. Who pays for a bug found two weeks after launch?
Both possible answers are legitimate, and the damage comes from leaving it unsaid. Under a fixed-price contract, defects inside the agreed scope are the vendor's to fix within a warranty window, and the length of that window is a negotiated term rather than an industry constant. Small engagements tend to settle around 30 to 90 days after acceptance, while a substantial build can carry a full year. We have signed year-long warranties often enough to say the number is worth pushing on, and nobody has ever added a warranty clause after acceptance. Under time and materials, the hours spent fixing a bug are billed like any other hours, the standard trade for the flexibility that model gives you.
The harder half is definition. Someone has to decide whether the thing you are looking at is a defect or a change of mind, and that argument is unwinnable once it starts. Settle the test in advance: a defect is behaviour that contradicts something written down. Then go and write down more.
A good answer puts a number on the warranty period, names who arbitrates, and offers an example from a real project.
A worrying answer is "we always look after our clients". Goodwill is genuine and has no duration, no scope and no arbiter.
10. What happens when the next iOS and Android releases land?
An app left untouched for a year does not stay where you left it. From 31 August 2026, Google Play requires new apps and updates to target Android 16, and existing apps targeting below Android 15 stop being available to new users on newer devices. Apple runs its own SDK deadlines on a similar annual rhythm.
So ask which minimum OS versions they plan to support, whether they test against the developer previews that ship each summer, and what a yearly compatibility pass costs as a number. Anyone who files that under "we can discuss it later" is describing the exact place where maintenance turns into an emergency. Doing nothing has a price, and it arrives as a slow disappearance from part of your audience rather than as an outage somebody reports.
Reading the answers before hiring an app developer
Ten answers produce a lot of signal, and hiring an app developer well comes down to knowing which of them are disqualifying and which are trade-offs you can price and live with.
Answers that should end the conversation
Some responses are worth walking away from regardless of how well the rest of the meeting went:
- No questions coming back at you. Anyone who takes a brief without probing your users, your deadline or the systems you already run intends to build exactly what you said, which is rarely what you meant.
- Hesitation about who owns the source code, or a repository you get invited to only once the last invoice is settled.
- A proposal with nothing in it about the months after launch. No warranty, no monitoring, no compatibility passes. The years you will be living with are the years they left out of the price.
- A price that falls when you push back while the scope stays where it was. Whatever was padding it is still padding something.
- Refusal to give you a client reference you can telephone. Written testimonials are marketing copy with a name attached.
Two more items belong in writing rather than in conversation. The first is ownership: store accounts, signing keys and the intellectual property assignment together settle whether you can walk the finished app over to somebody else, and every one of them is painless to agree on day one and close to impossible to agree during a divorce. We covered those mechanics, along with the three routes to getting an app built and what each one costs, in our guide to how to hire an app developer in 2026.
The second is the ending. Agree how much notice the supplier owes you before walking away, and what crosses the table when they do: documentation, credentials, and a working explanation of how the system fits together. Thirty days and a full handover is a fair floor to ask for.
Turning ten answers into a decision
Weight the ten by what you are building, because the same answer carries different risk depending on the app:
- Payments, accounts or personal data. Questions 2, 7 and 8 decide it. Unreviewed code and absent monitoring turn into a liability you carry personally.
- An existing app that needs more hands. Questions 1, 5 and 6 matter most, since what you are buying is integration into a team and a process that already exist.
- A first version on a tight budget. Questions 3, 5 and 9 protect you, because the cost of a first build is mostly the cost of the things nobody scoped.
For a product you expect to still be running in five years, finding a good app developer matters more than finding a cheap hour. We have sat on the answering side of these ten often enough to know which ones sting: Formstack Sign meant swapping a front end out from under paying customers who never noticed it happening, and work like that only survives when the review, the cover for absent people and the way back from a bad release are all boring and already in place. A company that cannot give ten straight answers about its own process will not give you straight answers about your project either.
FAQ: hiring an app developer
How many of these questions should I ask on the first call while hiring an app developer?
All ten fit comfortably in an hour, and asking them together beats spreading them out, since consistency across the answers tells you as much as any single one. If time is short, lead with the three that match what you are building and send the other seven by email. Judge the reply on how long it takes and how specific it is.
Is a portfolio enough to judge an app developer?
No, and treating it as enough is the most common mistake people make. A portfolio shows selected outcomes with no information about what they cost, how long they took, or who has since left. Use it for one thing: download the apps and check the version history for updates after launch. An app that shipped once and was never touched again tells you the client relationship ended early.
Should I ask a freelancer the same questions as an agency when hiring an app developer?
Mostly yes, with two adjustments. Question 1 becomes a question about what happens when they are ill or take a better offer, since there is no bench behind them. Question 7 usually gets an honest "I test it myself", which is fair at a freelance rate as long as you budget for a separate review before launch.
Can I ask these questions without a technical background?
Yes. None of the ten require you to read code, only to notice whether the answer is specific:
- Specific answers contain names, numbers, dates and examples from real projects.
- Evasive answers contain adjectives and reassurance.
- The follow-up that works every time is asking for an example of the last time it happened.
You are testing whether the person has been through this before, and people who have tend to answer immediately.
How much does hiring an app developer cost?
Marketplace freelancers cluster around $18 to $39, North American agencies charge $75 to $250, and Central and Eastern European software houses sit between the two. Treat every one of those as the price of an hour rather than the price of an app, since scope moves the total far more than any rate does. Realistic bands by app type are in our separate piece on custom mobile application development.
