I want to commission a mobile app: what should I prepare before talking to a software company?
If you want to commission a mobile app, write ten things down before you meet a software company: the goal, the users, the main user flows, example apps, the data and systems to connect, a budget range, a timeline, ownership, maintenance expectations and a success measure. They fit on one page, and they turn the first meeting from "what do you want?" into "this is what we want, under these conditions".
Why does it matter? Software companies price what you describe to them. "We need an app for our customers" can mean ten different scopes and therefore ten different quotes. When quotes differ that much, it is hard to tell which one is right. In projects that start without preparation, the usual outcome is scope that grows during development, a timeline that slips and a final "that is not what we meant" moment.
Preparing does not mean writing a technical specification. You do not need to know screen design or software architecture; that is the company's job. The questions you answer are about the business: what problem will the app solve, who will use it, will it earn money or cut costs, and what will you own at the end?
What does the 10-point preparation checklist look like?
The table below groups the ten points under seven headings. The "Ready when" column shows the concrete output you should have for each. You can take the filled-in table to the first meeting.
| Preparation | Ready when | If it is missing |
|---|---|---|
| Goal and success measure | One-sentence goal, measurable target | Nobody knows when it is done |
| Users and main flows | User types and a list of main flows | Scope keeps growing |
| Example apps | Three you like, one you dislike | Design expectations do not match |
| Data and integrations | Systems to connect and their owners | Workload appears late |
| Budget range and timeline | Range, target date, fixed-date events | Quotes cannot be compared |
| Ownership | Who keeps accounts and source code | You depend on the supplier |
| Maintenance expectations | Who maintains after launch, and for how long | Updates never happen |
How do you fill in the checklist step by step?
Write a few sentences for each point. It does not have to be perfect, because the company will ask about the gaps. What matters is that you separate what you know from what you do not.
- Goal: Write one business outcome, such as "reduce appointment cancellations" or "replace the field team's paper forms". If there are several goals, rank them.
- Users: Who will use the app? Separate customers, employees, managers and dealers; each means different screens and permissions.
- Main flows: List the five to eight core tasks in order: signing up, placing an order, paying, receiving notifications. For each flow, answer "what happens when it is finished?"
- Example apps: Name three apps you like and one you do not, and say why. It is the quickest way to explain what you expect from the design.
- Data and integrations: Which systems will the app talk to? Accounting software, ERP, CRM, payment provider, SMS provider. Note the owner of each and its technical documentation if it exists. Old, undocumented systems are usually the most uncertain part of a project.
- Budget range: Give a range rather than a single figure, and keep a separate allowance for maintenance. Stating a range makes it easier for a company to propose something that fits.
- Timeline: State the target launch date and any date that cannot move, such as a trade fair, campaign or season. Allow time for store review: Apple's App Review Guidelines and the Google Play developer policies show that apps are assessed against these rules before they go live.
- Ownership: Whose name will the store accounts be under? Will the source code be handed over? Who holds the domain, cloud accounts and design files? Settle this before you sign.
- Maintenance expectations: After launch, who fixes bugs, handles operating system updates and builds new features? Write these separately; maintenance and new development are different work.
- Success measure: What number will tell you after three months that the app works? Choose a business-linked measure such as active users, completed orders or fewer support calls, rather than downloads.
What should you know in advance about store accounts, privacy and security?
Three topics look small in a business plan but can stretch the timeline. The first is the store account. Apple allows membership of its developer programme as an individual or as an organisation, and Google Play offers two developer account types, personal and organisation. If you want the app published under your company name, plan for an organisation account and the documents it needs from the start. Account requirements can change, so check the current pages.
The second is privacy. In its review guidelines, Apple requires apps to link a privacy policy in the store listing and inside the app, and to state clearly what data is collected and how. If you collect user data, the information duty in Article 10 of Law No. 6698 (KVKK) also applies: users must be told who the data controller is, why the data is processed, who it may be transferred to, and how it is collected. Deciding up front which data you really need simplifies both the notice and the app.
The third is security. To set expectations for login, data storage and network communication, the OWASP Mobile Application Security Verification Standard (MASVS) is a useful benchmark. When you ask for quotes, simply ask "how do you handle security against MASVS?"; how concrete the answer is tells you something about the company.
What should you ask the company in the first meeting?
Preparation is not only about your answers; you should ask questions too. How concrete the replies are shows how well the company has understood the job.
- Similar work: Which comparable projects have you completed, and is there someone I can talk to about one of them?
- Way of working: How often will I see a working version during development, and how do you manage change requests?
- Delivery and acceptance: How will we prove the project is finished? Who runs the acceptance tests, and against which criteria?
- Team: Will the person I am talking to do the work, or will it be handed to another team?
- After launch: Are bugs found in the first three months covered? Do you quote for maintenance separately?
Write the answers down and keep them next to the quotes. Even if you only talk to one company, this list shows what you need to have written into the contract. For the general framework on picking a supplier, see our supplier selection guide.
For example: how does a prepared first meeting differ from an unprepared one?
For example, a spare-parts dealer wants an app where customers can see the status of their orders. Going in unprepared, the dealer just tells companies "an app with order tracking". Three companies send three quotes: one covers only an order list, one adds payments and notifications, and one includes stock-system integration. The quotes cannot be compared. The dealer picks the cheapest and later hears that "the stock connection was out of scope".
The same dealer then goes in with a one-page brief. Goal: cut phone calls. Users: customers and warehouse staff. Main flows: view order status, download invoices, receive notifications. System to connect: the accounting software. Success measure: fewer "where is my order?" calls in the first three months. A budget range and target date are written down too. This time every company quotes for the same scope, and the differences come down to approach, duration and working method. The scenario is hypothetical, but the same logic holds in real projects.
What are the most common mistakes when commissioning an app?
- Starting with a feature list: An "also this, also that" list hides the problem you are solving. Write the goal first and derive the features from it.
- Putting everything in version one: The main flows are enough for a first release. Add the rest once you see how people use it.
- Leaving ownership to the end: If the store account is in the supplier's name and there is no source-code handover clause, you have little leverage when you want to leave.
- Ignoring maintenance: Operating systems and store rules change. An app without a maintenance plan can run into problems after launch.
- Judging by price alone: Compare quotes against the same scope; the prices of two quotes with different scopes cannot be compared.
- Not talking to real users: Talking to three to five future users about a screen sketch before development avoids expensive changes.
How Hatson Tech helps
In its mobile application development solutions, Hatson Tech starts by completing the preparation checklist with you. The first meeting and discovery are free. We do not publish fixed prices, because price depends on scope and becomes clear after discovery. If your app will include AI, our guide to scoping an AI project and our article on choosing an AI supplier, which lists the questions to ask, will help. Prepare your list and bring it to us; we will fill the gaps together during discovery.