What problem should the app solve
A business needs an app when a process repeats every day and still depends on manual effort. The classic case is a spreadsheet where managers have tracked requests for years: eventually rows get duplicated, someone overwrites a colleague's data, and the owner no longer knows which number to trust. An app like this pays back not in revenue but in saved time and fewer transfer errors.
Most projects fall into one of three groups:
- customer-facing products: a personal account, booking, or an ordering app with payment through Click or Payme;
- internal systems: request tracking, warehouse, an operator panel, reports for management;
- integrations that connect your website, CRM, telephony, payment services and ad accounts.
Web app or mobile app: which comes first
A web app opens in the browser, needs no installation and updates for everyone at once. It is a sensible start when you are testing an idea or when the users are staff and partners. A mobile app earns its place when you need push notifications, offline work, the camera or geolocation. For couriers, drivers and field technicians it is often the only practical format.
Quite often the best answer is both, one after the other: a web version and admin panel first, then a mobile client built on the finished API. That is noticeably cheaper than building everything in parallel.
Local conditions matter too. Most users arrive from smartphones, not always powerful ones, and connections outside the capital can be unstable. So even a web app should be designed for the phone first and the desktop second.
What a sound development process looks like
It begins with a written description of the task: who the users are, which scenarios they go through, what happens after each action. The output is a list of screens and rules from which a budget can be calculated honestly instead of guessed.
Next come the interface and the data structure. You approve them, and only then is code written. Good teams work in iterations, so you see working pieces along the way rather than a finished product at the very end.
The project closes with testing on real phones, moving to a production server and a support period in which problems found by live users are fixed.
Set up analytics before launch
A common mistake is remembering analytics after release. Decide in advance which actions count as goals: registration, a placed order, a payment, a call to an operator. If events are built into the code from the start, you can see whether the app pays off and whether users come from Instagram, Telegram or search. If not, tracking has to be redone and the first weeks of data are lost.
What shapes the price and why deadlines slip
The cost of building an app is calculated from the project, not from a price list. The main factor is the number of scenarios and user roles: an app with one role and a handful of screens is a very different workload from a service with an account area, admin panel, payments and notifications. Beyond that, third-party integrations, design requirements and separate iOS and Android versions all move the number.
A good estimate is split into blocks, so you can see what to launch now and what to postpone. The timeline is also more honest as a range. An exact date appears only after scenarios are agreed; until then any date is a promise, not a plan.
Deadlines are usually broken not by code but by approvals: endless design revisions, missing content, waiting for access to a payment or accounting system. Those points are best written into the plan upfront.
Three mistakes when ordering an app
The first is wanting everything at once. A bloated first version costs more and reaches real users later, and real users are the ones who show what is actually needed. Build the minimum you can put in front of people.
The second is choosing a contractor on price alone. Very cheap development often means no testing and no documentation, and the difference comes back during support.
The third is failing to agree on rights. Source code, access to servers, databases and app store accounts should belong to you, with API documentation and deployment instructions delivered alongside. Prefer a widely used stack so a developer can be found in Tashkent and switching teams does not hurt.
Where to start if you only have an idea
Take a sheet of paper and answer three questions: who the user is, why they open the app and what they do inside. That is enough for a first conversation with a contractor and a rough budget.
If you want help framing the task, the markdev team can go through your project with you and say whether you need a website, a web service or a mobile client. We build websites turnkey and also run advertising, so we look at an app together with how its first users will arrive. Send us a message and we will go through your task.
FAQ
Should I build a website, a web app or a mobile app?
A website is enough to present services and collect requests. If you need accounts, orders or internal tracking, a web app fits. Choose a mobile app when push notifications, offline mode, the camera or geolocation matter.
How much does app development cost?
The price depends on the number of scenarios and roles, integrations, design and platforms. An exact figure is possible only after the task is described, so ask for an estimate broken into blocks.
Who should own the app's code?
Settle it in the contract before work starts. The right arrangement is that source code, server, database and app store access are handed to you together with documentation.
Why do development deadlines slip?
Most often because of approvals on the client side: design revisions, missing content, waiting for access to payment and accounting systems. Record these risks in the plan from the start.
Let’s look at your task for free
Leave your contact — in a 15-minute call we’ll show where leads get lost and what to fix first.