How much does app development cost

Two booking apps can look alike and still differ several times over in the work involved. One has a calendar and an email confirmation. The other has payments, partners who send offers, reviews, messaging and an admin panel. A package price would be too high for the first and unrealistic for the second.

So I quote only once I know the scope. What I can tell you up front is what drives the price. These are the main items, roughly in the order we go through them in the first call.

Each platform is work of its own. A web app runs in the browser and goes through no store review. A mobile app for iOS and Android can be written once, cross-platform, or separately for each system. Native development makes sense when the app depends on background work, Bluetooth or other system features, but it means two codebases.

You do not need all three at once. Many projects start with the web or with one mobile app and add the rest once there are users.

An app without sign-in is the simplest. Once users sign in, you need registration, email confirmation, password reset, account deletion and data protection. Sign-in with Apple or Google is easier for users, but it is still work.

Roles matter even more. An app where all users are equal is smaller than one with clients, staff, outside partners and admins, each with their own screens and permissions.

Card payments through Stripe or a similar service add screens for checkout, confirmations, refunds and failed payments. If payments also need fiscalised invoices, as in Croatia, the app has to connect to an invoicing service. Digital content sold inside a mobile app also falls under Apple's and Google's own rules, which need to be considered from the start.

Someone has to manage content and users: add a service, approve a partner, review orders, export data. The admin panel is a separate part of the app, usually on the web. It can be very simple, or it can grow as large as the app itself.

Connections to accounting, calendars, a CRM, SMS or email services, maps and similar tools each bring their own share of work. It is easier when the system has a good API and harder when data has to be pulled from files or an old program.

An app can use the standard iOS and Android elements that users already know. It can also have its own visual identity, animations and illustrations, which take longer. For a first version, a clean design in your company's colours and logo is usually enough.

The App Store and Google Play need developer accounts, listing text, screenshots, a privacy policy and answers to questionnaires about the data the app collects. Apple and Google review every version and sometimes ask for changes. The first release takes longer than later ones, and the Apple and Google developer accounts are paid for separately.

An app is not finished at release. Apple and Google ship new system versions every year, the services the app uses change, and users find bugs and ask for features. Server and third-party service costs come on top. Plan for maintenance from day one, not as a surprise six months in.

The biggest saving is in what you do not build yet. A first version should solve one problem for one kind of user and show that people actually use it.

• Start with one platform, or with the web, if your users are fine with that.
• Keep sign-in simple and add only the roles you really need.
• Handle rare cases by hand at first, such as refunds or exports for your accountant.
• Limit the admin panel to what you do every day.
• Leave custom illustrations and animations for later, unless they are central to your product.
• Write down every idea for version two, but do not build it until you see how version one is used.

A company that cleans holiday apartments in Istria wants an app for owners and cleaners. The first version can be a web app where the owner enters guest departures and the cleaner sees the schedule on a phone and marks the apartment ready. Payments, reviews and a store app can come once the system has proved itself.

A version like that ships sooner, starts saving time earlier, and gives you real data for deciding the next step.

In the first call, by phone, video or in person around Rijeka and Istria, we go through:

• what the app solves and who will use it
• which platforms make sense to start with
• what belongs in the first version and what can wait
• which outside services need to be connected
• what release and maintenance would look like

You get a proposed scope for the first version and a quote for it. If a ready-made tool already solves your problem well, I will tell you that too. I build the apps myself, so you talk directly to the person who will write and maintain yours.