What should businesses decide before commissioning a mobile app?

Deciding to commission a mobile app is not just about choosing which colors appear on the screen. You need to be clear about what problem the app will solve, who will use it and where it fits into the daily workflow. If these questions are answered before development begins, it becomes easier to compare quotes, keep the scope under control and accept the finished product.

Businesses often start with an idea: customers should be able to place orders, the field team should log visits, or the store should track inventory. Translate that goal into concrete tasks users will perform. What does the user see when they open the app, what information do they enter, and who is notified when the task is done? Thinking through these flows makes the requirements visible before any screen is designed.

Flutter or two separate native apps?

Flutter lets you build iOS and Android apps from a shared codebase. A large share of the screens and business rules can be shared. For many businesses that want to offer similar features on both platforms, this approach simplifies development and maintenance. Still, platform-specific permissions, store settings and some device features may need to be handled separately. A single codebase does not mean every feature will work without any platform-specific work.

With two separate native apps, each platform's own tools are used, such as Swift for iOS and Kotlin for Android. This choice can make sense if you need deep operating system integration or platform-specific interface behavior, or if separate teams already have established processes. The decision depends on the nature of the features, your existing technical team and long-term maintenance. Don't assume a single approach is right for every project. Ask the developer to explain the reasoning behind their recommendation, the platform-specific parts and how those will be maintained.

Write down the screens and flows first

You don't need a pixel-perfect design to get started. List the user roles and the tasks each role will perform. For example, a customer browses products, places an order and tracks its status; an administrator updates product information and manages orders. These flows later become the screen list and the development scope.

For each screen, note what information is shown and what action the user takes. Also consider situations such as an empty list, invalid input, a lost connection and unauthorized access. These are often part of the core flow. Sharing details like sample users, sample records and your current business process in the first meeting helps the developer raise unclear points early.

Keep the first version small

Instead of packing every idea into the first version, choose the few tasks that deliver the app's core value. Unnecessary features expand the scope and increase the number of scenarios that need testing. Releasing the core flow first and then improving it based on real usage feedback gives you a clearer roadmap. However, a small version should not mean skipping the parts needed for security or for the business to work correctly.

You can split features into three groups: those essential for the first version, those that can wait for a later version, and those that won't be built for now. This list prevents the scope from quietly growing whenever a new idea comes up. When a change request arrives, you can discuss how it affects the delivery date, the cost and the work already under way.

Do you need a server and an admin panel?

If the app will be a personal tool with data stored only on the device, you may not need a server. If multiple users need to see the same records, accounts must be created, content must be updated centrally or data must sync across devices, a server side is usually required. The server may include a database, user permissions and the services the app exchanges data with. An admin panel lets the business team manage information such as products, users, orders or content without changing the app's code.

Discuss the scope of these components openly with the developer. An admin panel should not be assumed to be essential for every project; but if the operations team needs to manage records, the need for a panel should be identified early. Who enters the data, who can change it and what information is visible to users are also business rules.

Publishing, accounts and handover

Submitting to the App Store and Google Play requires store listings, app information, images and builds that meet each platform's requirements. The review process depends on the store's rules; submitting an app does not mean it will be published immediately. The business should open the developer accounts in its own name and control access to them. That way, the app remains a publishing asset managed by the company. Clarify at the outset whose email address and payment details will be used to open the accounts.

State in the contract or statement of work that the source code and project files will be handed over to you. Handover is not just installing the app on a phone. The handover plan should include the code repository, the configuration needed to build and publish, a description of the services used, and account access. Secret keys should be managed securely and never written directly into the source code.

Break the work into phases and ask for a version you can try at the end of each one. Possible steps include flows and design first, then a basic working app, followed by server integrations and store preparation. At each phase, have it documented which tasks are complete and which gaps remain. That way, problems don't pile up until the very end.

Plan for maintenance

After release, operating system and store requirements may change. The packages used may need updates, and the server or content side may also require maintenance. Discuss in advance how bug reports, backups, monitoring, security updates and new feature requests will be handled. If it remains unclear who will handle maintenance and to what extent, even a small fix can stall.

Bring a short list of screens and user flows to the first meeting. Mark whether each item is needed in the first version, and put in writing who will control the user accounts, shared data, the admin panel and the store accounts.