Hiring the wrong app developer is expensive in a way that does not show up on the invoice. You pay for the build, then you pay again to fix it, then you pay a third time when a new team has to rewrite the whole thing because nobody can log into the App Store account. The best protection is a good conversation before you sign anything.
This guide gives you the exact questions to ask before hiring an app developer, whether you are interviewing a boutique iOS studio, an agency, or a freelancer. For each one you get two things most articles skip: what a strong answer actually sounds like, and the red flag version that should make you slow down.
At Iris, we answer these questions every week for founders who are vetting us. We wrote this guide the way we would want to be interviewed.
How to use this interview guide
- Pick 8 to 10 questions for a first call, not all 15. Save the contract and ownership questions for the second conversation.
- Listen for specifics over adjectives. “We use a CI pipeline that runs unit tests on every pull request” beats “we have a very rigorous process.”
- Ask follow-ups with the word “show me”. A good partner will happily open a repo, a TestFlight build, or a sprint board on screen share.
- Score every answer as you go. There is a scorecard template further down.
Part 1: Experience and fit (questions 1 to 3)
1. Which apps in your portfolio are closest to mine, and what was your exact role?
Portfolios hide a lot. Studios list apps they maintained for three weeks. Freelancers list apps where they wrote one screen.
| Strong answer | Red flag |
|---|---|
| “These two are closest. On the first we did discovery, design and the full native build, and we still ship updates. On the second we only did the iOS rewrite, the backend was the client’s team.” | Vague credit for big-name logos, no App Store links, or every app in the portfolio is a different category with no depth anywhere. |
Follow-up: “Can I download it right now?” Live links beat mockups every time.
2. Native, cross-platform, or hybrid, and why would you recommend that for my app?
This is the technical question that separates consultants from order-takers. The honest answer depends on your product, not on what the team happens to know.
- Native (Swift / SwiftUI for iOS): best for heavy animation, camera, ARKit, HealthKit, widgets, Live Activities, offline-first performance, and anything where the app is the product.
- Cross-platform (Flutter, React Native): reasonable when you need two platforms on a tight budget and the app is mostly forms, lists and API calls.
- Hybrid web wrappers: rarely the right call for a funded product, often a sign the team cannot do native.
| Strong answer | Red flag |
|---|---|
| “Given your onboarding is camera-heavy and you only need iOS at launch, native Swift is the better bet. If you tell me Android matters in six months, here is how that changes the math.” | One answer for every client, or “cross-platform is always cheaper” with no reference to your actual feature list. |
3. Who exactly will write my code, and will that person change?
Agencies sell with senior staff and deliver with juniors. This question is uncomfortable to ask, which is why you should ask it. An in-depth look at it is worth the time.
| Strong answer | Red flag |
|---|---|
| Named people, their seniority, their time zone, how many hours per week each is allocated, and who the backup is if someone leaves. | “We’ll assign the right resources from our pool.” Nobody will commit a name. Sales lead disappears after signature. |
Part 2: Process and communication (questions 4 to 6)
4. Walk me through your process from kickoff to App Store release
You are testing whether a repeatable process exists. Most teams describe some version of the standard stages:
- Discovery and scoping (goals, users, feature prioritisation)
- UX and UI design (flows, wireframes, prototype)
- Architecture and technical planning
- Development in sprints
- QA and testing (internal, then TestFlight with real users)
- App Store submission and review
- Post-launch monitoring, iteration and maintenance
| Strong answer | Red flag |
|---|---|
| A clear stage-by-stage walkthrough with named deliverables at each gate, plus an honest note on where projects usually slip. | “We’re agile, we just build.” Or a waterfall plan with a single delivery date nine months out and nothing in between. |
5. How often will I see working software, not a status report?
This is the single best predictor of a project that stays on track. A status email is a promise. A TestFlight build is proof.
| Strong answer | Red flag |
|---|---|
| “A new TestFlight build every week or every sprint, from week three onward. You’ll have access to the board and the repo from day one.” | “We’ll show you a demo at the end of each phase.” Long silences are where budgets die. |
6. What happens when I change my mind mid-project?
You will change your mind. Every founder does. The question is whether the contract handles it gracefully or punitively.
| Strong answer | Red flag |
|---|---|
| “Small changes get absorbed in the sprint. Anything bigger gets a written estimate in hours and cost before we touch it, and you decide whether it replaces something else in scope.” | Either “any change triggers a change order with a minimum fee” or the opposite, “sure, no problem, anything you want” with no process at all. Both end in conflict. |
Part 3: Code, accounts and ownership (questions 7 to 9)
These three are the ones founders forget and regret. Ask them before money moves.
7. Who owns the source code, the designs and the IP, and when does ownership transfer?
| Strong answer | Red flag |
|---|---|
| “You own 100% of the code, designs and assets. The contract assigns IP to you on payment of each invoice, so ownership accrues as we go. We’ll also list any third-party libraries and their licences.” | “We license the code to you.” Ownership only on final payment with no interim rights. Proprietary in-house framework you cannot take elsewhere. No answer on open-source licences. |
Why it matters: a GPL-licensed library buried in your codebase can create obligations you never agreed to. A proprietary framework means your only maintenance option forever is the team that built it.
8. In whose name are the Apple Developer account, repository and cloud services?
This is the lock-in question. Developers sometimes create the App Store listing under their own organisation account “to save time.” If the relationship ends badly, your app, your reviews and your ranking sit on someone else’s shelf.
| Strong answer | Red flag |
|---|---|
| “Your company opens the Apple Developer Program account and owns it. We get invited as developers. Same for GitHub, Firebase, analytics and any cloud provider. Billing goes on your card.” | “We’ll publish it under our account, it’s faster.” Repo lives in their private org. You have no admin credentials to anything. |
9. If we part ways tomorrow, what exactly do I receive?
Ask for the offboarding list in writing. Dignified teams have one ready.
- Full git history, not a zip of final files
- README with build and deploy instructions a new developer can follow
- Architecture overview and API documentation
- Design source files (Figma) with components intact
- All credentials, certificates, provisioning profiles and signing keys
- A handover call with the next team
| Strong answer | Red flag |
|---|---|
| A written exit clause in the contract listing deliverables and a handover window. | Hesitation, “that’s never happened,” or an offboarding fee that was never mentioned. |
Part 4: Quality, testing and security (questions 10 to 12)
10. How do you test, and what is automated?
“We test everything manually” means regressions will ship. You do not need 100% test coverage, you need coverage where it counts: payments, auth, data sync.
| Strong answer | Red flag |
|---|---|
| “Unit tests on business logic, UI tests on the critical flows, CI runs them on every pull request, plus a manual pass on a matrix of real devices and the two most recent iOS versions before each release.” | “Our developers test their own work.” No CI. No device matrix. No mention of older iPhones or smaller screens. |
11. How do you handle user data, privacy and App Store compliance?
Apple rejects apps for privacy issues more than almost anything else. Your developer should talk fluently about App Tracking Transparency, privacy manifests, required reason APIs, data minimisation, and keychain storage for secrets. If you handle EU users, GDPR comes up without you prompting.
| Strong answer | Red flag |
|---|---|
| “We fill the privacy nutrition labels with you, keep a privacy manifest for every third-party SDK, store tokens in the keychain, and never log personal data to analytics.” | “Privacy is a legal thing, that’s on your side.” Blank stare at “privacy manifest.” |
12. How will my app handle 10x the users, and what did you do last time something broke in production?
The second half of this question is the gold. You want a war story with a root cause, a fix, and a lesson. Teams that have never broken anything have never shipped anything meaningful.
| Strong answer | Red flag |
|---|---|
| “A sync bug corrupted local data for about 200 users. We caught it in Crashlytics within two hours, shipped a hotfix the same day, wrote a migration to repair the data, and added a regression test.” | “We’ve never had an issue.” Or blaming a previous client for everything. |
Part 5: Budget, timeline and life after launch (questions 13 to 15)
13. How do you scope and price, and what is explicitly not included?
Fixed price, time and materials, or a hybrid discovery-then-build. All three can work. What matters is that exclusions are written down.
| Strong answer | Red flag |
|---|---|
| “Here is the feature list with hour ranges, here is what sits outside scope: backend hosting costs, content writing, App Store assets beyond the basics, third-party SDK fees, Android.” | A single number with no breakdown. A quote given before any discovery call. A price far below every other bid, which usually means the scope gap arrives later as invoices. |
14. What does post-launch support look like, and what does it cost?
Apple ships a major iOS version every autumn. Devices change. SDKs deprecate. An app with zero maintenance degrades within a year. Someone has put together a good summary of it.
| Strong answer | Red flag |
|---|---|
| “30 to 90 days of warranty on defects at no cost, then a monthly retainer covering OS updates, crash monitoring, store compliance and a set number of improvement hours. Response times are in the contract.” | “We’ll be around if you need us.” No SLA, no warranty period, no named cost. Support only sold as a large annual contract you must sign before launch. |
15. Can I speak to two clients, including one where the project went badly?
The best vetting question nobody asks. Any team can produce a happy reference. The tell is how they respond to the second half.
| Strong answer | Red flag |
|---|---|
| “Sure. One project went over because we underestimated a third-party integration. Here’s the client, and here’s what we changed in our estimating since.” | References never materialise. Only written testimonials with no company names. Defensiveness. |
Bonus questions by situation
If you are hiring a freelancer
- What other projects are you running in parallel over the next three months?
- What is your plan if you get sick or take a contract that pays more?
- Who reviews your code?
- Are you comfortable working directly with my designer or backend team?
If you are hiring a studio or agency
- What is your current team utilisation, and when can you actually start?
- Is any part of this project subcontracted, and to whom?
- Who is my single point of contact, and what happens when they are on holiday?
If you already have an existing app to take over
- Will you run a paid technical audit before quoting?
- What would you rewrite versus keep, and why?
- How do you ship your first release without breaking existing users?
A simple scorecard for comparing candidates
Score each area from 1 to 5 right after the call, while it is fresh. Weight ownership and support heavily, they are the areas that cost the most to fix later.
| Area | What you are scoring | Weight |
|---|---|---|
| Relevant experience | Shipped apps in a similar category, live links | High |
| Process clarity | Defined stages, weekly builds, visible board | High |
| Code and account ownership | IP assignment, your Apple account, exit clause | Critical |
| Testing and quality | Automated tests, CI, device matrix | High |
| Privacy and compliance | App Store rules, GDPR, data handling | Medium |
| Post-launch support | Warranty, retainer, response times | Critical |
| Communication fit | Clarity, pushback, honesty about tradeoffs | Medium |
Five red flags that should end the conversation
- A firm quote before any discovery. Nobody can price a product they have not scoped.
- Refusal to put IP transfer in writing. There is no good reason for this.
- Publishing under their own Apple account. It is a leash, not a convenience.
- No references, ever. Logos on a website are not references.
- Agreeing to every request instantly. A partner who never pushes back is a vendor who will build the wrong thing politely.
What good looks like on our side
We publish our answers to all 15 of these questions before a contract exists: you own the code and the Apple Developer account from day one, you get a TestFlight build every week, scope changes get an estimate in writing before work starts, and every project ends with a documented handover whether or not you stay with us. If you want to run this interview with us, bring the hard questions. Those are the fun calls.
FAQ
What are the 7 stages of app development?
Discovery and strategy, UX and UI design, technical architecture, development, testing and QA, App Store launch, then post-launch maintenance and iteration. Any developer who cannot name these stages and tell you what you receive at the end of each one is improvising. Originally covered on https://chopdawg.com.
How do I hire a developer for my app idea?
Write a one-page brief with your goal, target users, must-have features and budget range. Shortlist three to five candidates from App Store credits, referrals or vetted directories. Run a 45-minute call using the questions above, request a paid discovery or audit from your top two, then compare the written scopes rather than the headline prices.
How much should I expect to pay for an iOS app in 2026?
A focused MVP from an experienced studio typically lands in the low tens of thousands, a feature-rich consumer app with backend, payments and a design system runs considerably higher, and freelancers are cheaper upfront but carry single-person risk. Budget an extra 15 to 20 percent of build cost per year for maintenance, store compliance and OS updates.
Can I just build my app with AI instead of hiring a developer?
AI tools are excellent for prototypes, internal demos and validating an idea quickly. Shipping a production app on the App Store is a different job: signing and provisioning, privacy manifests, review compliance, accessibility, performance on older devices, crash monitoring and ongoing updates. Most founders use AI to sharpen the brief, then hire a developer to build something maintainable.
Should I hire a freelancer or an app development studio?
Freelancers suit small, well-defined scopes with an experienced product owner on your side. Studios suit projects needing design, iOS, backend and QA working together, and they carry continuity risk better because one person leaving does not stop the project. Ask the continuity questions above either way.
What should be in the contract before work starts?
Scope with explicit exclusions, payment schedule tied to deliverables, IP assignment terms, account and credential ownership, confidentiality, warranty period for defects, support terms with response times, and a termination clause listing exactly what gets handed over.