The honest answer to “How much does an app cost?” is that it depends on what the app does. That is not very helpful, so let’s start with the numbers and then explain what moves them.

The short answer

In Croatia in 2026, a mobile app built by a small studio or freelancer typically costs:

Tier What it includes Timeline Price
Simple 5–8 screens, no sign-in, content from one source 4–8 weeks €3,000–€6,000
Mid-sized User accounts, backend, notifications, sometimes payments 2–4 months €6,000–€13,000
Complex Offline support, integrations with other systems, admin panel, multiple roles 4–8 months €13,000–€25,000+

These ranges cover both platforms (iOS and Android) built from a single codebase. If you need two separate native apps, expect to pay 40–80% more. We explain this further in our article on choosing a technology.

What actually drives the cost

The cost is driven less by the number of screens and more by the number of states the app needs to handle. A simple list screen is inexpensive. A list that works offline, syncs when the connection returns, and resolves conflicts when two users edit the same record can cost ten times more—even though the specification may look the same.

User accounts and roles

Sign-in itself takes only a few days. The work comes from everything around it: password recovery, account deletion (required by Apple), different permissions for owners and employees, and inviting team members. One role is inexpensive; three roles with different permissions are not.

Payments

Integrating Stripe or a similar service is not the hard part. The complexity lies in everything around it: what happens when a card is declined, how an expired subscription works, who gets a refund, and how it is recorded. If you charge customers in Croatia, you also need fiscalization, which is a separate project in its own right.

Offline support

Often underestimated. If people use the app in the field—in a marina, parking lot, or basement—it cannot depend on a signal. That means a local database, a sync queue, and rules for resolving conflicts. It typically adds 40–80 hours and changes the app’s architecture, so adding it later often means substantial rework.

A rule of thumb: any feature that must keep working when something goes wrong—no network, no disk space, or the user closes the app mid-recording—costs several times more than the same feature under ideal conditions. When you receive a quote, ask what happens in these situations.

Why quotes can differ threefold

You may receive quotes of €4,000 and €14,000 for the same project brief. It is usually not about greed; the quotes often describe different products:

  • Different assumptions about scope. A cheaper quote may assume the design is ready, the backend already exists, and there is no admin interface. A more expensive quote may include all of that.
  • Testing. A thorough quote includes testing on real devices. A cheaper one may leave it out, and you pay for fixes later.
  • App store release. Preparing store materials and getting through Apple’s review can take longer than the final week of development.
  • What happens after handoff. If maintenance is not mentioned in the quote, that does not mean it will not be needed. It means it has not been priced yet.

Costs people often forget

In addition to development, budget for these items. They are not large, but can be surprising because they are billed separately:

  • Apple Developer Program — around $99 per year, required while your app is on the App Store.
  • Google Play — a one-time $25 fee.
  • Backend and database — free at low usage, rising to a few dozen euros a month as your user base grows.
  • Legal documents — terms of service and a privacy policy. Apple requires them for app release, and GDPR has its own requirements.
  • Maintenance — typically 15–20% of the development cost per year. iOS and Android release new versions every year, and something always needs updating.

How to reduce the cost without making the app unusable

The biggest savings come from reducing the first version’s scope, not negotiating the hourly rate:

  • Start with one platform. If your users are tradespeople working in the field, they are probably on Android. Start there.
  • A spreadsheet can replace the admin panel. With ten clients, a ready-made tool may be enough to manage your work. Build a custom interface when the limitations actually get in the way.
  • Delay payments. You can invoice your first users manually. Add in-app payments once you know people are willing to pay.
  • Use existing components. Designing every button from scratch can look great, but it is expensive.

We explain how to shape a first version in our article about building an MVP in six weeks.

What to look for in a proposal

A good proposal answers these questions without being asked: which platforms are included, who handles the design, what happens to data offline, how many design revisions are included, who publishes the app, and what maintenance costs after handoff. If any of this is missing, the proposal is incomplete—not cheaper.