Questions to ask a mobile developer before you commit

Every mobile developer will tell you they're the right fit. The only way to test that claim before money changes hands is to ask questions that force specifics instead of reassurance. A confident answer sounds different from a vague one — you just need to know which questions surface the gap.

"Who actually writes the code — you or a subcontractor?"

Many small studios and freelancers outsource parts of a build without saying so upfront. This matters because if the person quoting you isn't the person coding, your communication chain gets longer and accountability gets murkier.

A good answer names the actual people or team involved, and is upfront if some work goes to a specialist (payment integration, say, or a specific animation). An evasive answer stays vague — "we have a team" — without ever landing on who you'd actually be dealing with when something breaks.

"What happens when the app store rejects an update?"

This question tells you whether the developer has shipped real apps under real conditions, not just built demos. App store review is unpredictable, and rejections happen even to experienced teams.

Listen for a specific process: they resubmit within a defined turnaround, they know the common rejection reasons for your app's category, and they don't charge you extra for fixing something they should have caught. If they act like rejection is rare or someone else's problem, they haven't shipped much — or they're not planning to stick around for it.

"Who owns the code and the accounts once we're done?"

This is the question people forget until it's too late. Ownership of source code, app store developer accounts, and any backend infrastructure should sit with you, not the developer, once the project ends — otherwise you can't move to another provider or make changes without them.

Ask directly:

• Will the app store account be registered under your business, not theirs?
• Do you get the full source code repository, not just a compiled build?
• Who holds the domain, hosting and any third-party service logins?

A developer who answers plainly and puts it in writing is being straight with you. One who says "we'll sort that out later" is keeping leverage over you for future work — even if that's not their intention, it's the effect.

"What does 'done' actually include?"

Ask this before scope discussions get technical. It reveals whether the quote you're comparing against others even covers the same ground — testing on real devices, basic analytics, a privacy policy that satisfies POPIA obligations, or just the visible screens working in a demo.

A developer who's thought this through will list what's in and what isn't, and flag the grey areas — like whether bug fixes after launch are included or billed separately. Someone dodging the question with "don't worry, we'll cover you" is setting up a scope argument for later, usually once you've already paid a deposit.

Reading the tone, not just the answer

Beyond the words, notice how a developer handles a question they clearly haven't been asked before. Do they think out loud and give you a real answer, or do they smooth it over and move on? The second pattern tends to repeat once you've paid a deposit and the leverage has shifted.

If you're not confident enough in mobile development to judge the technical answers, at minimum ask for their business registration details, examples of apps they've shipped, and a reference you can actually call. Comparing a few candidates side by side on these exact questions — rather than on price alone — is usually how the real difference between developers shows up. Strove lists vetted app developers if you'd rather start from a shortlist that's already been checked than screen every candidate from scratch.