Colombo --:--:--UTC+05:30
Spacewalk guides · Free checklist
Published by Imdad Ismail
Before you hire an app developer or studio, ask each candidate the same questions and compare their answers side by side. This checklist has 15 questions to ask an app developer, in five groups: past work, how the project will run, release and the app stores, ownership and handoff, and support after launch. Each question comes with why it matters and what a clear answer covers, so you can tell a specific answer from a vague one.
It is written for founders, small-business owners and product owners hiring someone to build a mobile or web app, and does not cover what an app should cost or how to word the contract. Spacewalk builds mobile and web apps, so we may be one of the developers you compare. Our own answers to the ownership questions are near the end of the page.
Download the app developer scorecard
Version 1 · 30 October 2026
The scorecard is free and needs no sign-up or email address. Both files list the same 15 questions as this page, with a column for each developer. We checked the Word file in Apple Pages on 30 October 2026; it has not been tested in Microsoft Word or Google Docs yet. To report something out of date, email hello@spacewa.lk.
Note each developer's answers during or straight after the call. If a developer can't answer a question yet, ask what they need from you to answer it. For a web app with no app store release, skip questions 8 and 10, and ask question 9 only about the privacy policy. Question 12 covers the domain and hosting.
Why it matters: A live app in the App Store, on Google Play or on the web shows finished work that someone released and kept running, which a design or prototype cannot show.
A clear answer covers: Links you can open yourself, and what the developer did on each: design, development, release, or all three. For client work they can't name, a description of the problem and their part in solving it.
Why it matters: Most of a project's risk usually sits in one or two parts, such as offline use, payments, an integration with an existing system or an AI feature. Experience with those parts tells you more than experience in your industry.
A clear answer covers: A specific project where they built that part, what turned out harder than expected, and how they would approach it for you.
Why it matters: The person on the first call is not always the person who writes the code, and some studios pass parts of the work to subcontractors.
A clear answer covers: The people or roles covering design, development and testing, whether anyone outside their team is involved, and who your main contact is.
Why it matters: An estimate depends on the brief behind it, so a developer who quotes without asking questions is guessing at the scope. Our app requirements template covers the points most developers ask about.
A clear answer covers: A list of open questions about your brief, and how they will settle them before giving a fixed price: more questions by email, a short call, or a separate paid scoping step.
Why it matters: A short first release reaches real users sooner and is easier to estimate and test. Without an agreed split, the scope tends to grow while the project runs.
A clear answer covers: A must-have list for the first release, a separate list of later ideas, and how changes to either list are agreed and priced.
Why it matters: Using a working build early shows misunderstandings while they are still small.
A clear answer covers: Builds you can install yourself, through TestFlight on iPhone or a testing track on Google Play, or a staging site (a private test copy) for a web app. Ask how often you will get a new one and who you talk to when something looks wrong.
Why it matters: Problems that users find after launch end up in store reviews and support emails, and on the app stores a fix has to ship as a new update.
A clear answer covers: Which devices and operating-system versions they test on, whether testing is manual, automated or both, and who checks a fix before the next build goes out. For a mobile app that handles personal or payment data, also ask how they check its security, for example against the OWASP Mobile Application Security Verification Standard (MASVS).
Why it matters: A release needs screenshots, a description, privacy details and answers to the store's questions as well as the app itself. Apple and Google both review apps, and Apple's App Review can ask for changes before an app goes live.
A clear answer covers: Who writes and prepares each part of the listing, who submits it, and what happens if review asks for changes. No developer can guarantee approval, so treat a promise of one with caution.
Why it matters: Apple's App Store privacy details cover data collected by third-party code in your app, such as analytics or advertising SDKs, as well as your own. The answers have to match what the app actually does. Apple has required them for new apps and updates since 8 December 2020, and Google Play has required its Data safety form since 20 July 2022.
A clear answer covers: Who lists the data the app and its SDKs collect, who fills in Apple's privacy details and Google Play's Data safety form, who writes the privacy policy, and who updates all three when the app changes.
Why it matters: An app in the App Store or on Google Play sits in the developer account that published it. Moving it to another account later is possible but has conditions: Apple's app transfer criteria include at least one version already released on the App Store, and Google Play requires both accounts to be set up and in good standing.
A clear answer covers: The app is published under your organization's Apple Developer and Google Play accounts, and the developer works in them through access you grant: a role such as App Manager or Developer in App Store Connect, and user permissions in Play Console. Apple allows only one Account Holder per account, and that person should be in your business.
Why it matters: Without the source code, another developer can't fix the app or build on it.
A clear answer covers: The code lives in a repository you own or can access, such as on GitHub or GitLab, and the contract says who owns it and from when. You also get what is needed to build and release it, including the settings for every service it uses. This page is not legal advice; ask a lawyer in your country to check the contract.
Why it matters: Most apps rely on more than the app stores: a domain, hosting, a database, email sending, analytics, payments, maps or an AI model provider. Accounts left in the developer's name keep the app tied to them after the project ends.
A clear answer covers: A list of every service, who pays for it, and a plan to open each one in your business's name or move it to you at handoff.
Why it matters: Handoff decides whether you can keep the app running without the original developer.
A clear answer covers: Access to the code, accounts and services from questions 10 to 12, notes on how to build and release the app, and a list of known issues.
Why it matters: Phones get new operating-system versions every year and the app stores change their requirements, such as Google Play's target API level requirement, so an app needs updates even when its features stay the same.
A clear answer covers: Whether support is included for a period or arranged separately, how you report a problem, and how urgent fixes are handled.
Why it matters: Projects end for ordinary reasons: the budget runs out, priorities change, or development moves in-house. The exit is easier to agree before you start.
A clear answer covers: The handoff from question 13 at any point in the project, and the notice either side gives.
| Mark | What it means |
|---|---|
| Clear | Names who does the work, what you receive and how it is agreed. |
| Vague | Agrees in principle, with no names, steps or written terms. |
| Missing | No answer yet, or "we'll sort that out later". |
Ask which live apps they have built, who will work on your project, what goes into the first release, how you will see progress, who submits the app to the stores, whose accounts it will be published under, who owns the source code, what you receive at handoff and who maintains the app after launch. The 15 questions above cover each one.
Send every company you are considering the same brief and ask each one the same questions, then compare the answers side by side before you compare prices. Look for specific answers on scope, testing, release and ownership. A developer who asks questions about your brief before quoting has started working out what the project needs.
For a business app, use your own organization's Apple Developer and Google Play accounts and give the developer a role in each. Apple asks companies to provide a D-U-N-S Number, a business identifier assigned by Dun & Bradstreet, to enroll as an organization; individuals don't need one. If the app is already in the developer's account, Apple and Google both allow transfers between accounts, subject to conditions.
It depends on your contract, so check that it states who owns the code and when ownership passes to you, and that the code is kept in a repository you can access. This page is not legal advice. For the contract itself, ask a lawyer in your country.
Vague answers to the ownership questions, no live apps to show, a promise of App Store approval, a fixed price with no questions about your brief, and no plan for updates after launch. Any one of these may have an explanation. Several together are a reason to keep looking.
If you are comparing us with other developers, these are our answers to the ownership questions.
| Question | Our answer |
|---|---|
| 10. Developer accounts | We publish your app under your organization's Apple Developer and Google Play accounts and work in them through the roles you grant us. Apple's Account Holder role stays with someone in your business. |
| 11. Source code | We keep the code in our own repository while we build the app, and you can see it there at any time. Once you have paid in full, we move it to your repository, such as on GitHub, and ownership passes to you. You also get what is needed to build and release the app. |
| 12. Other services | We open the domain, hosting, database and any other services in your business's name, or move them to you at handoff. |
| 13. Handoff | You get access to the code, accounts and services, notes on how to build and release the app, and a list of known issues. If we stop working together before the project ends, you get the same handoff for the work you have paid for. |
Email your brief to hello@spacewa.lk and include any of the 15 questions you want us to answer. Spacewalk builds web applications, mobile apps and AI features. We are based in Colombo, Sri Lanka, and available worldwide.
Imdad Ismail runs Spacewalk, a software development agency in Colombo, Sri Lanka. He is a software engineering graduate and has spent more than ten years building transport, food, inventory and order systems for multinational companies. Alongside client work, he builds and supports two apps of his own: Countstead, an inventory app for small businesses on iPhone and iPad, and Imprimo, a flashcard app for iPhone that uses spaced repetition. You can find him on LinkedIn.