App Design Guide: Key Decisions Before You Order

If you've asked a few teams to quote on an app idea, you've probably seen prices and timelines that look nothing alike. That usually isn't the vendors' fault. Each one read your fuzzy idea in its own way. This app design guide helps you make the key decisions before you order and capture them in a short brief. You end up with a document you can hand to any vendor, and quotes you can actually compare.

What decisions should you make before ordering app design?

The short answer: before you order, get clear on the user's problem and whether you need an app at all. Then decide on the first version's features, the build approach, target platforms, integrations, and the budget for both building and maintaining the app. Put the decision-maker, vendor selection criteria, ownership of code and accounts, delivery terms and the support plan into that same short brief. Each section of this guide unpacks one of those decisions.

This guide is about buying decisions, not about how to build. It won't tell you what the technical team does week by week. If you want the order of development stages, read the mobile app roadmap from idea to launch. Here the focus is on what you, as the client, need to settle before development starts.

One thing up front: you don't need a firm answer to every question. Wherever you're unsure, write "needs investigation" next to it. A confident guess today turns into a fixed price and a rigid contract later. A good vendor takes honest uncertainty seriously and proposes a way to look into it.

An app design guide starts with defining scope

Most misunderstandings start with one word: "design." Many clients think app design means drawing screens. When a vendor hears the word, they usually picture the whole job. So first, be clear about which parts you mean:

• Understanding the need: who the user is, what they're trying to do and where they get stuck today.

• User experience: flows, screens and how the app behaves in normal and abnormal situations.

• Building the software: the app, the server, the admin panel and integrations.

• Testing: checking that every flow works on real devices.

• Operational readiness: publishing, monitoring and getting your team ready to respond.

A question I hear a lot: what is a custom app? It's software built around your business's defined needs, not on a one-size-fits-all template. But custom doesn't necessarily mean writing a separate app for each operating system. A large share of the code can be shared and the product can still fit your work perfectly.

Two terms come up again and again in this guide. A brief is a short document stating the project's goal, users and constraints. Scope is the boundary of the work: what's in the order and what's out.

Say you want a booking system for a service business. "Booking app" is one thing in your head, but in practice it has several parts: a customer app, a panel for front-desk staff, and maybe a separate app for specialists to see their schedule for the day. These aren't one scope, and each has its own cost and timeline.

So the output of this stage is a simple list: which roles use the system and which component each role needs.

Does your business need an app?

Not always. An app makes sense when users come back regularly, it solves a real problem for them, and installing it is worth their while. "The CEO wants an app" or "everyone else has one" isn't reason enough.

The first question I usually ask is: "How often does a user deal with you?" Someone who buys once a year will hardly bother installing an app. Someone who orders every week or logs their work every day genuinely benefits from one.

For a first filter, I use this rule of thumb:

• Infrequent visits and simple needs: first assess and improve the mobile experience of your current website.

• Frequent processes, like reordering or daily logging: an app is more worth exploring.

• Work that depends on a device capability that doesn't run reliably in the browser: an app becomes a serious option.

Watch out for outdated assumptions, though. Camera, location and even notifications are sometimes available on the web, depending on the browser and device. So "we need the camera" isn't, by itself, a verdict to build an app. Test the real need on your own audience's devices.

The output here is three short sentences: why you'd build the app, the evidence you have today, and the conditions that would postpone the decision. For example: "If most orders come from one-off customers, we'll improve the website first." Keep in mind that the rules in this guide are for initial screening, not final technical rulings.

What problem should the app solve for users?

A problem worth building for usually fits in one sentence. Fill in this template: "A specific user, in a specific situation, trying to do a specific task, runs into a specific obstacle." If you can't fill in all four blanks, it's too early to order.

A purely hypothetical example: a service company notices that customers call several times to find out when the technician will arrive. The first temptation is "let's build a technician-tracking app." But the reason for the calls might be something else. Maybe the confirmation SMS doesn't give an exact time, or customers don't know where to ask for a change. Don't pick a solution until the cause is clear.

To find the cause, talk to a few real users. Keep the questions short and about the past, not about wishes:

1. The last time you did this, what exactly happened?

2. How do you do it now: by phone, through a messaging app or in person?

3. Which part took the most time or frustrated you the most?

4. If you gave up halfway, what did you lose?

Then write down the user's main flow: starting point, key action and successful end. For example: "The customer sees the appointment SMS, confirms or reschedules, and receives a final confirmation." Don't confuse your need for reports with the user's need. Reports matter to you, but nobody installs an app to look at your reports.

The output of this section is one prioritized problem, with its evidence and the result you expect to change, such as fewer follow-up calls. If you take only one section of this guide seriously, I'd make it this one.

What features should the first version have?

Only the features that complete the user's main flow and test your core assumption. This version is called an MVP, or minimum viable product: the smallest product a real user can work with, and one that teaches you something from how they behave. That said, an MVP doesn't mean an incomplete, fragile or insecure product.

To sort features, put each one into a category and write a user-facing reason for every essential item. The table below is for a hypothetical store with 200 products:

A loyalty program may matter later, but it answers a different question: "Do customers come back?" If you don't yet know whether customers will buy through the app at all, that question is premature.

Take one common mistake seriously: failure states are part of scope, not decoration for the next version. If a product sells out mid-purchase, a payment fails or the connection drops, what does the app do? From a QA perspective, most first-week complaints come from these states, not from features that were cut.

Build the first version small, not half-finished. Cut features, not care.

So the output of this section is three lists: prioritized features, a short acceptance condition for each essential feature, and an explicit list of what the first version won't do. Don't underestimate the third list. Most later disputes are about exactly these unwritten items.

App builder, web app or custom development?

The answer depends on your need, not on which approach is "better" in general. An app builder is a tool that assembles apps from ready-made components with little coding. A web app runs in the browser and can be fully custom. So these categories aren't completely separate.

In practice you have three paths. They differ in product limitations, how they reach users, and room to grow:

Notice there's no "cheaper" row in this table. The cost of each approach depends on scope and on how long you use it. A ready-made tool can be cheap at the start and get expensive as usage grows.

If you're leaning toward a ready-made tool, check these before choosing:

• Can you export your data, including users and orders, in a usable format?

• Can it connect to your payment gateway, SMS provider and accounting software?

• What are the usage limits, and what happens when you hit them?

• If you ever want to leave, what are the exit terms?

Also be aware of a common shortcut: wrapping your existing website in an installable shell. It looks like an "app," but if the site is slow or confusing on mobile, those problems come along with it. The site's weak integrations stay right where they are, too.

Output: your preferred approach, the reason in two sentences, and one technical uncertainty to test with a small prototype. For example: "Does barcode scanning work in the browser on our warehouse staff's phones?" This part of the guide isn't meant to choose for you. It just makes sure your choice has a reason behind it.

Android and iOS: a shared experience with what differences?

The core experience can be the same on both platforms, but the behavioral details differ and need separate testing. When ordering Android and iOS apps, first decide which one you'll release first. Base that decision on evidence: which phones your audience uses, how accessible publishing is on each platform, and who will support two versions.

Two terms are worth knowing. Native development means building the app with each operating system's own tools. Cross-platform development means a large share of the code is shared across operating systems. The choice depends on how much you need device capabilities, who will maintain the app, and your growth plans. We cover the details in our comparison of native and cross-platform app development.

But shared code doesn't mean shared testing. These behave differently on the two systems:

• Notifications and how permission to send them is requested

• Camera, location and file permissions

• Navigating back between screens, which on Android has a dedicated button or gesture

• Payments: going to the gateway and coming back from it

• Work the app does in the background

Some markets add another layer. If your audience is in Iran, for example, check before signing which channel you'll publish through, which accounts you'll need and how updates will reach users. Channel rules change, so check them again when you place the order. For quality criteria, Android's official app quality guidelines are a good reference.

Output: your priority platform, the minimum OS version you'll support, and the scenarios that must be tested on real devices, not just emulators. In the brief table at the end of this guide, these go into the "Build approach and platform" field.

What experience should be validated before coding?

Test and sign off the user's main flow on an interactive prototype before any code is written. A prototype is a clickable mock-up of the screens, without the full software logic. Users tap buttons and move from screen to screen as if it were the real app. Approving colors and the home screen is no substitute for this test.

In a hypothetical service-booking system, for example, walk through the entire flow with three or four target users: choose a service, choose a time, confirm, then cancel or reschedule. Most snags turn up in that last part, because nobody usually spends time on it.

In design, look at these states too. This guide counts them as scope, not cosmetic details:

• Empty states: when there are no orders yet, or a search returns nothing.

• Errors and waiting: a clear message on failure and a loading indicator when things are slow.

• Text size: when the user has enlarged the font on their phone.

• Right-to-left layouts: icon direction, numerals, and mixed Persian and English text.

• Poor connectivity: how the app behaves on a slow or flaky connection.

Not all feedback carries the same weight, though. "I don't like this blue" is taste. "The user couldn't find the confirm button" is an observable problem. My suggestion: make one person responsible for approving the design and give them a deadline to respond. Scattered opinions from several managers can stall design for weeks.

Output: a list of approved flows and the uncertainties that remain. A claim that "the design is fully complete" is rarely accurate, so it's better not to write it into any meeting minutes.

Connecting to your website, admin panel and other services

Your app is almost always connected to other things: your website, inventory, payment gateway, SMS provider or accounting. These connections run through an API (application programming interface), a defined channel through which two systems exchange data. In my experience, integrations cause the most surprises in estimates. That's why they get their own section in this guide.

First, identify the source of truth for each piece of data: where it really "lives" and where it's only displayed:

If two independent panels change the same data with no rules, sooner or later you'll see one price on the website and another in the app.

Then, for each integration, note its purpose, who owns the service, whether documentation exists, access to a test environment, and any costs or usage limits. A payment gateway with no test environment can, on its own, throw the whole schedule off.

Make sure you ask the vendor about one scenario: if the payment service drops for a moment during checkout, what happens? Users will naturally tap the button again. The app shouldn't create a duplicate order or payment from that retry.

For the admin panel, don't settle for a list of pages. Define roles and say what each role can change. Ask for an activity log so you can see who changed a price. A panel that takes ten clicks to log a return sends staff straight back to their notebooks.

Output: a list of integrations and who on your side is responsible for preparing each one. If you plan to reuse your current website, tie that decision to a technical review of the site, because not every site is ready to connect to an app.

What data should be collected and protected?

Collect only the data you need to deliver the service. Don't request access to contacts, location or files just because it's technically possible. Every extra permission both lowers user trust and increases your responsibility.

Next, define what data each role can access. A support agent may need to see a customer's phone number, but not their full payment history. Write down now how long data will be kept and how users can delete their account or their data.

That's why security should be an acceptance condition, not something for "later." A few simple tests you shouldn't skip:

• Can a user see another user's order or profile just by changing an ID?

• Does sensitive information remain on the phone after logging out?

• How are passwords, keys and payment details stored and transmitted?

If you work in a sensitive field like health or financial services, take a specialist security review seriously. Legal requirements also vary from sector to sector, and there's no generic version. No app design guide replaces your legal advisor, so check this part with them.

Output: a list of the data you collect, the permissions you request from users, and the essential controls. For more depth, see security requirements in mobile app design.

How do you estimate the build and maintenance budget?

Estimate the budget piece by piece, and take any number seriously only alongside its scope. A single figure for "a store app" tells you nothing, because you don't know what's in it. This breakdown helps you put proposals side by side:

Running costs are the ones many people forget. Servers, SMS, external services like maps or push notifications, error-monitoring tools and support all have recurring costs. So does keeping up with new operating system versions. An app that isn't maintained will, after a while, stop working properly on newer phones.

The estimate format this guide recommends has four parts. Ask vendors to structure their estimates the same way:

1. Base cost for the agreed scope

2. Optional items, each priced separately

3. Items explicitly outside the contract

4. The assumptions the estimate is based on

The fourth part matters most. If the estimate assumed the payment gateway has complete documentation and it doesn't, the cost changes, and nobody is at fault. For high-risk uncertainties, a limited technical review before a fixed price makes more sense; at Niasa, that's usually what we suggest. Set your contingency based on the listed risks, not an arbitrary percentage.

Now suppose the estimate comes in above your ceiling. Cutting low-priority features like wishlists or sharing is perfectly reasonable. But cutting testing or security to hit that number means buying a risk you'll pay for later, at a higher price.

Bring the budget down by cutting work, not by cutting rigor.

Output: an internal budget ceiling that you keep to yourself, a conditional estimate range from each vendor, and a payment schedule tied to reviewable deliverables rather than elapsed time.

How are the timeline and client responsibilities defined?

A good timeline is a list of reviewable deliverables, each with its prerequisites, not just an end date. "Interactive prototype of the booking flow, provided we receive the service descriptions" is trackable. "App ready by the end of the quarter" isn't.

Some of those prerequisites are in your hands, not the vendor's. Before work starts, settle these:

• The final decision-maker: one person, not a meeting

• Turnaround time for answering questions and giving approvals

• Content: copy, product images, terms and conditions

• Access to services: payment gateway, SMS, server, internal software

• Legal and financial sign-off, if needed

Say access to the payment gateway arrives a few weeks late. Agree in advance on what stops and what keeps going. Final payment testing pauses, but the other flows and the admin panel keep moving. Write this into the plan so that a delay doesn't later turn into a blame game.

Define the change process from day one, too, because changes will come:

1. Log the change request in writing.

2. The vendor assesses and reports its impact on cost and time.

3. You approve it before it's implemented.

Output: a list of responsibilities, dependencies and the approval rule. For the full sequence of execution stages, see the roadmap introduced at the start of this guide.

How do you evaluate vendors and technical proposals?

You can only compare proposals fairly when they're all written against the same brief, the one this guide builds step by step. If a vendor made a different assumption, say Android only, ask them to state that difference separately. Otherwise you're comparing apples and oranges.

A technology name on its own isn't a measure of quality. Instead, ask every vendor these questions:

• Why do you recommend this build approach for us?

• What do you see as the biggest risk in this project?

• Who does the testing, and on which devices?

• What's not included in your proposal?

The answer to that last question tells you a lot. A vendor who honestly lists what's outside the contract is usually more transparent during delivery as well.

Look at portfolios carefully, too. The real question isn't how pretty the screens are. It's what problem was solved and what exactly the team's role was: design, development or both?

The proposal should also spell out the deliverables, each side's responsibilities, how progress is reported and how scope changes are handled. This part of the guide only covers the minimum criteria for completing your brief. For a fuller list, see the checklist for choosing an app development company.

Output: the open questions for each proposal and a defensible reason to choose or reject it, one you could explain to a partner or the board.

Delivery, access ownership and acceptance criteria

Define acceptance with testable scenarios. "The app should work without problems" can't be measured, and that exact sentence is what causes disputes on delivery day. A good scenario says what's done and what result should be visible.

For example: "After a confirmed payment, exactly one order is created, and its status is the same in the admin panel and in the customer app." Anyone can test that, and the result isn't up for debate.

Write the delivery list before work starts:

• Source code, as specified in the contract

• Documentation for running the system and redeploying it on a server

• Design files

• Settings and files needed for publishing

• An operations guide for staff

Then separate out ownership. The code repository, where versions of the code are kept, should sit on an account you control. The same goes for publishing accounts, servers, services and app signing keys. Take the signing key seriously: without it, updating the same app can become difficult or even impossible.

Owning your data isn't the same as owning every tool, though. The data may be yours, but the SMS or maps service belongs to another company and comes with its own terms. Make legal ownership of the code and licenses for third-party components clear in the contract.

From a QA point of view, write down three more things: the devices and versions testing will cover, which bug severities block acceptance, and how much time you have to review a delivery. A typo on a minor screen shouldn't block acceptance of the whole release. A duplicate order should.

Output: an acceptance annex and an access list, both attached to the contract. Of all the outputs in this guide, these two carry the most weight on delivery day.

What needs to be ready to publish the app?

Publishing isn't just an install file. Accounts, listing information and your own team's readiness all need to be in place. Treat publishing as separate from technical delivery, because a finished app file doesn't guarantee the channel will approve it.

Prepare these in advance:

• A publisher account in the name and identity of the actual business owner

• Product description and screenshots

• A way to contact support

• Privacy information and a data retention policy

Choose your distribution channels based on what your audience can actually access, which in Iran differs from many other markets, and on each channel's current rules. Those rules change, and there's no permanent or guaranteed workaround. So read the official text before submitting; Apple's official App Store Review Guidelines, for example, spell out what gets an app rejected.

In this guide, operational readiness counts as part of publishing. Staff should know how to answer users' questions. Initial data, like prices and stock, must be correct. Error monitoring should be switched on, and you should know in advance how you'll limit the damage if something serious goes wrong, for instance with a staged rollout or by temporarily turning off a feature.

Output: an owner for each prerequisite, your release channel or channels, and a condition that must be met before you publish.

How are support and post-launch changes separated?

Post-launch work comes in three kinds, and each has its own rules. Bug fixes correct behavior that doesn't match the agreed scope. New features are things that weren't in scope. Compatibility maintenance keeps the app current with new operating system versions and services. If these three get mixed up in the contract, every request turns into an argument.

Also, don't confuse initial response time with resolution time. "We'll respond within a few hours" means someone has seen the problem, not that they've fixed it. Define severity levels for incidents. For a serious one, like payments going down, have an emergency contact path.

Several operational duties need an owner: error monitoring, renewing services and the domain, backups and testing data restores. Having a backup file isn't enough on its own. Until you've tried a restore at least once, you don't know whether that file will actually help you.

Walk through a hypothetical with the vendor: your payment provider changes how its integration works. Who notices? Who assesses the impact and quotes the cost of the change? If the answers aren't clear, the support contract isn't finished yet.

Output: the support scope, exceptions, who owns operations, and how the project would be handed over to a new team if you ever switch vendors. This is the part of the guide clients usually skip until the first serious problem.

How do you measure an app's success after launch?

Success metrics should tie back to the problem you built the app to solve, the one you wrote down in a single sentence in the problem section of this guide. Install count alone isn't a sign of business value. An app that's installed but unused just takes up space on a phone.

For the same hypothetical service company, these metrics mean more: the share of started requests that get completed, how many people come back for their next request, and the trend in calls caused by uncertainty about arrival times.

Measuring requires analytics events, meaning a record of a specific user action such as "request submitted." Define each event's name, when it's recorded and what data may be attached to it before development. You can add events after launch, but you'll have lost the data from the first few weeks.

Be careful when interpreting results, though. If a new ad campaign started at launch, or your customer mix changed, a before-and-after comparison will mislead you. Two changes happening at the same time doesn't prove one caused the other.

Output: a small number of metrics, each with a definition, a data source and someone responsible for reviewing it. Every review should end in a decision: continue, adjust or stop a feature.

Checklist for preparing a quote request

If you're asking what you actually need to do to get an app built, the practical answer is this: gather the decisions from this app design guide into a one-page brief and keep the unknowns separate. A short brief gets read. A twenty-page document usually doesn't.

For example, the hypothetical service company that wanted to reduce uncertainty about arrival times would have a brief like this, in eight fields:

This initial brief doesn't replace technical specifications or contract annexes. Its job is to give every vendor the same starting point. When you fill in the build approach field, go back to the native vs. cross-platform comparison in the Android and iOS section. The vendor selection checklist will help with choosing a vendor, and the roadmap from the start of this guide will help with planning the build.

Then send your quote request with these three parts:

1. The shared scope, meaning this brief, for every vendor

2. Open questions labeled "needs investigation"

3. A request to separate running costs from build costs

The next step is simple. This week, fill in the table above with your team and leave the gaps honestly blank. If you'd like, you can review the brief with us through Niasa's mobile app design and development services. We usually clear up the open questions together first, then move on to the estimate.