How much does a custom web app cost in 2026, and what are you actually paying for?

You ask three companies to quote "a booking app" and get three sums that look nothing alike. Usually nobody miscalculated. Each vendor pictured a different app.

The price of custom software isn't set by the number of screens or the programming language. It's set by what the app must do, for whom, with which data, and what happens when something goes wrong. Below are the factors that move the price, what a quote must contain so you can compare, and the costs that show up after launch.

What drives the price

The number of complete workflows. A workflow runs from start to finish: a request becomes an approved quote, a booking lands in the calendar and a confirmation goes out, an order reduces stock. Each workflow adds screens, rules, error cases and tests. It is the biggest cost driver.

Roles and permissions. An app used by one type of user is simpler than one where the client, the employee and the manager see different things. Every role means access rules that must be built and checked.

Integrations. A link to an existing system (invoicing, ERP, payments, couriers) can be an import from a file or a two-way sync over an API. The second costs more: errors, retries and the moments when the two systems disagree all have to be handled.

Existing data. Starting from scratch means no migration. Years of data in spreadsheets or an old program mean someone has to clean, match and import it without losing anything.

The kind of app. A responsive web app works on phones, tablets and desktops. Native mobile apps (App Store and Google Play) are usually another project. Platforms with several separate organisations, and complex subscriptions, are separate stages too.

Operational requirements. Who may see what, how fast data must be recoverable after a problem, who is alerted when an error occurs. None of this shows in a demo, but all of it is paid for in the build.

What a fair quote must contain

A sum without a written scope can't be compared with another sum. Ask for:

• The scope written as workflows, with acceptance criteria: what a user must be able to do for the delivery to count as done.
• What is included and what isn't. The exclusions say at least as much as the inclusions.
• Who owns the source code and when you receive it.
• What happens after handover: a defect-fixing period, and what counts as a defect versus a new feature.
• Recurring costs: hosting, external services and maintenance, estimated before you sign.
• The timeline and what depends on you: access, materials, testing and approval.
• Payments tied to deliveries, not to hours spent.

The costs people forget

The build price is only part of it. After launch come:

• Hosting and external services. Servers, the database, outgoing email and any paid API, including AI models, whose cost grows with use.
• Maintenance. Security updates, adjustments after feedback and small improvements. A monthly plan or on-demand work, but it has to be planned.
• Your team's time. Someone has to explain the process, test with real data and approve. A good app needs a few real hours a week from you, not just at the end.

A concrete example: how we price it

At PhantomTech the first stage has a fixed price: the Build Sprint, €6,000 (30,000 lei) excluding VAT. For that, we build one complete workflow with up to two roles and one agreed integration or import. We publish it on a private review link within 10 working days, counted from scope confirmation and receipt of access and materials.

What you get:

• a kickoff workshop, the workflow and main screens, and written acceptance criteria;
• a responsive web app with saved data and test access;
• one revision round within the agreed scope (defect fixes don't use it up);
• the source code, account access, a recorded walkthrough and instructions, after approval and full payment;
• 30 days of defect fixes from the approved handover.

Payment is 60% at booking and 40% at approved handover. Estimated separately: additional workflows, native mobile apps, multi-organisation platforms, complex subscriptions and large migrations. Hosting, API usage and maintenance are estimated before booking and paid separately.

For a larger product, the sprint is the first usable part, not the whole project. The benefit is that you see working software before deciding on the next stage. Details are on the Build Sprint and pricing pages.

How to lower the cost without lowering the quality

• Start with the workflow that matters most. Add the rest once the first is in use.
• Import before integration. A file import can validate the process; an API sync can follow once you know exactly which data moves.
• Responsive web before native. For many internal processes, a good web app on a phone is enough.
• Settle the rules before the build. Who approves, what happens on cancellation, which fields are required. Every rule discovered at the end costs more than one written at the start.

Questions to ask before you sign

1. Which complete workflow will I be able to use at the end, and how do we check it's done? 2. What is not included in this quote? 3. When do I receive the source code and account access? 4. What monthly costs will I have after launch, and how much are they estimated at? 5. What happens if I find a defect after handover? 6. What do I need to do, and by when?

If you want to know what your app would cost, book a free call. We'll pin down the workflow together and see whether it fits in one sprint or needs several stages.