Which Question Comes Before the Decision to Commission an App?
One question comes before everything else: which problem are you solving? If the answer won't fit into a single sentence, neither will the scope. The screen list, the technology and the budget all come after that sentence. The most expensive mistake in commissioning an app is starting to draw screens before defining the problem. Those screens end up in the bin.
Most meetings open with a list of screens. But a list is a solution, and nobody says which problem the solution belongs to. We don't talk about screens in the first session. We ask this: how does this work run today, and where does it get stuck?
Once the answer becomes concrete, the scope narrows of its own accord. If the problem your app solves fits into a single sentence, the brief fits onto a single page.
Who answers that question matters too. When the decision is taken by the person who does the work in the field, the product comes out closer to reality. Apps described only around the management table tend to fill up with screens nobody opens. Invite at least one user to the first session.
The Practical Way to Get the Problem Down to One Sentence
Fit the sentence into this template: “[who], [in what situation], cannot do [what].” If the template won't fill, the problem isn't defined yet. Teams that come to a commissioning meeting with that sentence end up with a markedly narrower scope than those who don't.
How Often Will Your User Open the App?
Frequency is the sharpest measure of whether an app is needed at all. A product that gets opened several times a week deserves one. For a transaction carried out three times a year, a mobile-friendly page will do. Take the decision to commission an app on that behavioural data, not on feeling. If you don't have the data, gather it first.
The interval between uses determines whether the product stays on the home screen. Nobody makes room for an icon they will open twice a year. How often your existing site is visited is a good indicator here; the repeat rate there gives you the real answer.
Without measurement you guess, and guessing gets expensive. Even a simple month of logging firms the decision up. We took up the relationship between user behaviour and interface decisions separately in the user experience article.
When you measure frequency, don't look at a single number. How long it takes the same user to come back tells you more than total visits. A product a hundred people visited once and one ten people visited ten times each look the same in the table, yet as a case for commissioning an app they are diametrically opposed.
Does a Low Frequency Kill the App Idea?
No, but it changes the order. Build the mobile-friendly flow first, then watch the data. If the frequency rises, your case for commissioning an app is no longer a guess but a measurement.
Does This Job Call for an App or a Mobile Site?
Four criteria settle the decision: frequency of use, the need for notifications, offline working and hardware access. If even one of them is essential, an app starts to make sense. If none of them applies, a mobile-friendly site does the same job for less. Test the wish to commission an app against those four criteria, not against fashion.
The browser has come a long way in recent years. Camera, location and offline caching now work on the web side too. But sending an instant alert, tracking location in the background and appearing on the store shelf are still an app's work.
Making that distinction early protects the budget. We opened up which items move the cost, item by item, in the app cost article. And we set out the stages and the schedule in the development process article.
Test the four criteria one by one, not as a block. Most teams stop at the sentence “let's send notifications” and ask nothing further. Yet if an email or a text message does the same job, the need for notifications alone is not a case for commissioning an app.
When Does the Single Codebase Question Come Up?
After the decision to build an app is settled. The choice of architecture is a separate discussion; we explained the single codebase approach on the service page. We opened up the difference in mechanism in the native or cross-platform article. Don't disturb the order of decisions: the rationale first, the technology second.
Where Will the Data Sit, and Who Will Own the Code?
Look for two lines in the contract: ownership of the source code, and where the data will be held. Without those two lines, the product isn't yours. The store accounts should be opened in your own name too, not the agency's. Not asking about these in a commissioning meeting is the most expensive silence there is. Put the handover term in writing from the start.
This heading looks legal rather than technical, yet both lead to the same door. Whoever holds the software holds the product's future. When you want to change agency, these lines are what save you.
Set three things up in your own name: the store developer accounts, the domain and the cloud account. Let the development team join those as guests, not as owners.
Where the data sits is a separate question. If you process personal data, the server's country, the retention period and the deletion procedure should all be written into the contract. Adding those lines later, on a product already live, is both expensive and slow. If the app collects personal data, the data controller obligations under KVKK — KVKK is Türkiye's personal data protection law — should be written into the contract from the outset.
How Is the Handover Made Painless?
Let repository access, environment variables and the setup document be shared from day one. The decision to commission ties down not the app's last day but its first; the handover is discussed when it begins, not when it ends.
“In case the processing of personal data is carried out by another natural or legal person on behalf of the data controller, the data controller shall jointly be responsible with these persons for taking the measures laid down in the first paragraph.”
— Personal Data Protection Authority (KVKK), Personal Data Protection Law No. 6698, Art. 12
Which Five Questions Should You Ask the Agency?
Five questions reveal an agency's real capacity. Have you released a similar product in the stores? Who draws the error states? How do maintenance and code handover work? Ask for the answers in writing. A commissioning meeting isn't an exam, it's a rehearsal for working together. If your questions don't get clear answers, the problem isn't at your end.
What a team can do is shown less by its portfolio than by the answers it gives to your questions. Ask the five below in order and take notes on the answers.
- Release experience — in which stores have you released a similar product?
- Error states — who draws the empty list, the broken connection and the timeout?
- Maintenance — how does the process work when a new operating system version comes out?
- Handover — how do the source code and the accounts pass to us?
- Communication — who reports weekly progress, and in what form?
If the answers stay verbal they get forgotten. Ask for them in writing; let them go into the annex of the quote.
Why Isn't the Portfolio Enough on Its Own?
The work in the window appears finished; how it got finished doesn't. Whether an app released two years ago is still standing today tells you more. Look it up in the store and check the date of the last update. Glance at the reviews too: whether the faults users reported were answered tells you more honestly about a team's maintenance habits than any portfolio.
Let's Answer Your Questions Together
You don't have to answer most of these questions on your own. In the meeting we talk through the problem, the user and the frequency of use together. What you are left with is not a list of screens but the rationale for a decision. Take the decision to commission an app on that rationale and you won't have to turn back later. The first three months spent on the wrong product never come back, whatever the budget.
What Do You Take Away from the Scoping Session?
You leave the scoping session with a single page in hand: the problem, the user, the frequency, the four criteria and the handover terms. Our mobile app service page is always open if you'd like to look through it. Putting the rationale for your app in writing before you commission it makes every decision that follows easier.
App or mobile site? The four criteria
If users open your product a few times a week, build an app; a few times a year, a mobile site will do. Instant alerts, offline work and camera or sensor access make an app essential. Store-shelf presence tips the scale towards an app. Email, a constant connection and search visibility point to a mobile site.
| Criterion | An app is needed | A mobile site will do |
|---|---|---|
| Frequency of use | A few times a week | A few times a year |
| Need for notifications | Instant alerts essential | Email is enough |
| Working offline | Must work without a connection | Always online |
| Hardware access | Camera, sensors, background location | Not required |
| Store visibility | Being on the shelf matters | Search engines are enough |
Does the Decision Start with Technology or a Question?
The decision to commission an app begins with a question, not with technology. Once you put the problem, the user, the frequency and the handover terms in writing, every remaining decision gets easier on its own.