Choosing who builds your app is the biggest decision in the project, bigger than the feature list or the launch date. A weak website can be rebuilt in a few weeks. A weak app, built on code you do not own and published under an account you cannot access, is much harder to recover from. We build apps for a living, so treat this guide as a buyer's checklist written by someone on the other side of the table: the questions below are the ones we would ask if we were hiring.
If you are still working out whether you need an app at all, start with mobile app vs mobile website. If you are working on the budget, our guide to how much a mobile app costs comes first. This page assumes you have decided to build and now need to pick a team.
1. Who owns the source code when the project ends?
This is the question that matters most and the one buyers ask least. Under US copyright law, the person who writes code is generally its author unless a signed written agreement says otherwise, and "work made for hire" wording often does not do what people think it does. The safe version is a clause stating that the company assigns the copyright in the app code and designs to you, effective on final payment, in a signed document. We explain the legal mechanics in who owns your website after launch; the same reasoning applies to an app. This is general information, not legal advice, so have your own lawyer read the contract.
Also ask what is excluded. It is reasonable for a company to keep ownership of its own reusable components and open-source libraries, which come with their own licences. It is not reasonable for the whole app to be "licensed" to you with no way to take it elsewhere.
2. Whose name are the store accounts in?
An app is published through a developer account with Apple and another with Google Play. The account holder appears as the seller. Create both accounts yourself, under your registered business name, and give the developer team access. Apple's organisation enrolment needs a legal entity, a D-U-N-S number and a website, which takes time, so start early. The full list is in our guide to publishing an app on the App Store and Google Play. A company that insists on publishing under its own account is holding your app hostage, whatever the reason given.
3. Can I download something you have already built?
Screenshots are easy to produce. Ask for links to live apps in the App Store or Google Play that the company built, then install them. Check how they feel on a real phone, how they handle a poor connection, and whether the ratings and update dates show a product that is still looked after. Ask what the company's role was, because agencies sometimes show work they only designed. Our own examples are on the portfolio page.
4. How do you scope and price the work?
Ask the company to describe how it turns an idea into a written scope. A serious team will run a discovery stage, produce a list of screens and features, and tie the price or milestones to that list. Be wary of a quote that arrives within a day with no questions asked. Then ask how change requests work: what happens when you add a feature in month two? A fixed price protects you only if the scope is written down, and hourly billing protects you only if there is a regular report of hours used. Our design brief template was written for websites, but its structure works well for an app brief too.
5. Native, hybrid or cross-platform, and why?
There is no single right answer. Native apps for iOS and Android generally give the deepest access to device features and the best performance. A cross-platform build serves both platforms from one codebase and is often faster to launch and cheaper to maintain. What you want to hear is a recommendation tied to your app's actual features. If every answer is the same framework no matter what you describe, the company is selling its stack rather than solving your problem.
6. How will the app be tested?
An app has to work across screen sizes, operating system versions and network conditions, and emulators miss problems that real devices expose. Ask which devices the team tests on, whether you get a test build to try before launch, and who handles the app store review. Apple and Google both review submissions, and a rejection can add days. A team that has published apps before will talk about this without being prompted.
7. What happens after launch?
Operating systems update every year, and an app that is never updated eventually breaks or is flagged by the stores. Ask what support is included, for how long, what it covers and what is billed separately. Ask who fixes a crash at 9 a.m. on a Monday. Put the answers in the contract and in your budget, not in a verbal promise.
8. Who will actually do the work, and who do I talk to?
Ask for a single point of contact, how often you will get progress updates and whether the people who pitched the project are the ones building it. Subcontracting is common and not a problem in itself, but you should know about it. Ask how you will see progress: a staging build you can install beats a status email.
Red flags worth walking away from
- The company will not let you own the developer accounts or the code.
- No live apps you can download, or references that cannot be contacted.
- A fixed quote with no written scope, or a vague promise that "everything is included".
- Guaranteed downloads or ranking. Nobody can guarantee either, and a company that does is guessing.
- Pressure to sign this week for a discount.
A simple way to compare your shortlist
Send the same short brief and the same eight questions to every company, then lay the answers side by side. Score each answer on whether it is specific, written down and favourable to you. The cheapest quote often leaves out testing, store submission or support, so compare what is included before you compare totals.
Where Zenesa fits
We build iOS, Android and cross-platform apps for businesses across the US, and we are happy to answer all eight questions above in writing before you commit. Read about our mobile app development service, or contact us with a short description of your idea and we will reply with the questions we would ask first.
