How much does a web application cost in 2026: price ranges for a customer portal, an internal system and a SaaS platform

The operations director of a mid-sized distributor in Bavaria has three proposals on her desk for a B2B customer portal. Customers should be able to place orders, track deliveries, download invoices and raise returns, and the portal has to talk to an ERP system the company has run for a decade. The first proposal comes in at €45,000, the second at €130,000, the third at €340,000. All three look professional, all three have a timeline, and all three promise a “modern technology stack”. The managing board asks her what the portal will actually cost, and she cannot answer, because she does not know whether the three proposals are pricing the same thing.

This is not an exception. It is how the market for software development services normally works. The figure in a proposal is the result of an equation the vendor rarely shows: how many people, in which roles, for how many months, at what rate. Once you know the equation, you stop comparing three numbers and start comparing three sets of assumptions. Very often the cheapest proposal turns out to exclude testing and the ERP integration, and the most expensive one prices features you do not need yet.

This article shows how much a web application costs in 2026 for three common project types: a customer portal, an internal system and a SaaS platform. We do not quote “market averages” pulled from nowhere. Every range is derived from stated assumptions: team composition, duration and the rate scale published on our pricing page. You can swap any assumption for your own and recalculate the result in a spreadsheet in five minutes.

Why do three quotes for the same web application differ by a factor of three or more?

Because they are almost never quoting the same application. A request for proposal describes the product in sentences, and each vendor turns those sentences into hours according to its own interpretation. “Customers can see their invoices” can mean a screen listing PDFs uploaded by hand, or a synchronisation with the ERP every five minutes, with credit notes, search and permissions for several people on the customer side. The effort gap between those two readings is several-fold, and both fit inside the same sentence of your RFP.

The second source of spread is the scope of services around the code. One proposal prices developers and nothing else. Another adds a QA engineer, environment set-up, continuous deployment and a project manager. A third adds a business analyst, a UX designer and a risk contingency. All three talk about “building the portal”, but only one builds it in a way that can be maintained safely for years. The cheapest quote is often not cheaper at all. It shifts part of the work onto you, or onto later.

The third source is rates and team mix. A team made up mostly of juniors has a lower day rate but needs more days and more supervision. A senior team costs more per day but makes the architectural decisions that are hard to reverse more quickly and more reliably. Rates alone do not tell you which quote is cheaper in total.

The fourth source is contingency. A vendor that accepts the risk of a fixed price on an unclear scope has to price that risk. That is why fixed-price quotes on a poorly described scope are often noticeably higher than time-and-materials quotes for the same work. We explained the mechanism in detail in our article on who really pays for risk transfer in fixed-price software.

The practical conclusion: before you compare totals, ask each vendor to break the proposal down into roles, person-months and rates. Only then can you see whether a difference comes from price or from scope.

How do you work out the cost of a web application without guessing?

The cost of building an application is the product of three quantities: the number of people on the team, the time they work and the rate. Everything else, the technology, the number of screens, the integrations, the security requirements, affects the result through those three variables. More integrations mean more people or more time. Stricter security means more expensive roles and more testing. Every quote can therefore be reduced to one formula, and that makes it checkable.

This article uses the following assumptions, all of which you can change:

• Rates. We use the senior band from our rate card: a senior developer costs EUR 335-485 per day, fully loaded. For simplicity we price every role in this band. In reality frontend developers are slightly cheaper and architects and DevOps engineers more expensive, so in a mixed team the differences partly cancel out. For context, our pricing page notes that senior rates are roughly 35-55% below the average German IT freelance rate of EUR 95 per hour reported by Freelancer-Kompass 2025.
• Time. We assume 18 billable days per month per full-time person. A month has around 21 working days, but holidays, public holidays and sick leave reduce the days actually worked and invoiced.
• Cost of a person-month. From the two assumptions above, one senior person-month costs between 335 × 18 = EUR 6,030 and 485 × 18 = EUR 8,730.
• Contingency. We add a separate 15% contingency for requirements that will only become clear once users see a working system.

The lower bound of each range is the shorter schedule at the lower rate; the upper bound is the longer schedule at the higher rate. A team with more mid-level specialists can go below the lower bound, because their rates are lower. Our MVP cost calculator works the same way: its lower bound combines a narrower scope with mid-level rates, its upper bound a fuller scope with senior rates.

An important caveat: this is not an ARDURA price list and not a price promise. It is an estimation method with stated assumptions. We price every project individually. The point of these numbers is that you go into a vendor conversation knowing what order of magnitude to expect and how to read proposals.

How much does a customer portal cost?

A customer portal is a web application where your customers serve themselves: they place orders, track status, download documents and raise complaints. Its defining feature is that it rarely stands alone. It almost always shows data from systems you already run: ERP, CRM, warehouse management, invoicing. The cost of a portal therefore depends more on integrations than on the number of screens.

Team assumptions. A typical team is 4 full-time equivalents on average: two full-stack developers, a QA engineer at half time, a UX designer at half time, a business analyst or project manager at half time and a tech lead with DevOps skills at half time. Schedule: 4-6 months to a production release, including discovery.

The arithmetic. 4 people × 4 months = 16 person-months. 4 people × 6 months = 24 person-months.

• Lower bound: 16 × EUR 6,030 = EUR 96,480
• Upper bound: 24 × EUR 8,730 = EUR 209,520
• With 15% contingency: roughly EUR 111,000-241,000

What fits inside that range: sign-in with company accounts and several user roles on the customer side, a catalogue with customer-specific prices, ordering, order status and history, invoices, a simple returns module, an admin panel for your staff, a two-way ERP integration plus one further system, automated tests of the key journeys, and test and production environments.

What pushes a portal to the top of the range or beyond: an ERP without a documented API, so the integration has to run through files, database views or a middleware layer; complex price lists with tiered discounts and promotions; several languages and currencies; and accessibility requirements if the portal serves consumers. The European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025 to, among other things, e-commerce services for consumers, so in a B2C portal accessibility is a legal requirement, not an add-on.

There is also a narrow variant. A portal that at launch only shows order status and invoices, without online ordering, can be built by a smaller team in less time. At 2.5 FTE for 3 months that is 7.5 person-months, or roughly EUR 45,000-65,000 before contingency. That is often a sensible first step: you find out whether customers actually want to serve themselves before you invest in a full ordering module.

How much does an internal business system cost?

An internal system is an application for your own staff: request workflows, resource planning, job tracking, an operations dashboard that replaces spreadsheets and email threads. It is usually cheaper than a customer portal for two reasons. Its users are trained and fewer in number, so the interface can be simpler and the performance requirements are modest. And it does not have to fight for conversion or first impressions.

It has two traps, though, that raise the cost more than boards expect. The first is data migration: data in spreadsheets and old systems is inconsistent, duplicated and incomplete, and cleaning it can take as long as building a module. The second is business rules that live in people’s heads: a process “everyone knows” turns out to have a dozen exceptions that somebody handles by hand. Each exception means extra logic and extra tests.

Team assumptions. 3 full-time equivalents on average: two developers, a QA engineer at half time, a business analyst or project manager at half time. The team builds the interface on an existing component library. Schedule: 3-5 months.

The arithmetic. 3 × 3 = 9 person-months. 3 × 5 = 15 person-months.

• Lower bound: 9 × EUR 6,030 = EUR 54,270
• Upper bound: 15 × EUR 8,730 = EUR 130,950
• With 15% contingency: roughly EUR 62,000-151,000

Before you decide to build an internal system, ask the question a custom software vendor does not always ask: could you get the same result by configuring a tool you already own, or by buying an off-the-shelf SaaS product? If the process is generic, such as leave management, a simple CRM or service tickets, an existing tool will usually win on total cost. A custom system makes sense when the process is a source of competitive advantage, or unusual enough that off-the-shelf tools would force workarounds. We set out that decision in detail in our guide to custom software development in 2026, including a five-year comparison of building versus subscribing.

How much does a SaaS platform cost?

A SaaS platform is a product you sell to many customers on subscription. Technically it is the hardest of the three types, because on top of the business features it needs a whole layer that a portal or internal system does not: multi-tenancy with data isolation, self-service sign-up and onboarding, subscription billing, plans and limits, an operator admin panel, an audit trail and often an API for customers. Then there are requirements that quickly become purchase conditions when you sell to businesses: single sign-on (SSO), data export, event logs and a stated service availability.

Team assumptions. 6 full-time equivalents on average: three developers (backend and frontend), a tech lead or architect, a QA engineer, a UX designer at half time and a product owner or project manager at half time. DevOps work is included in the tech lead’s and developers’ time; for products with high availability requirements it is worth making it a separate role. Schedule: 7-10 months to a version 1.0 you can sell to your first paying customers.

The arithmetic. 6 × 7 = 42 person-months. 6 × 10 = 60 person-months.

• Lower bound: 42 × EUR 6,030 = EUR 253,260
• Upper bound: 60 × EUR 8,730 = EUR 523,800
• With 15% contingency: roughly EUR 291,000-602,000

That is version 1.0, not an MVP. If you are still testing whether anyone will pay for the product, do not build the full platform straight away. A first version for a handful of pilot customers can skip self-service sign-up, automated billing and granular permissions, which takes several months off the schedule. We covered MVP budget phases and the usual traps in our guide on how to budget MVP development, so we will not repeat them here.

A SaaS platform also has running costs the other types do not. If you take card payments, the payment provider charges a fee on every transaction. Stripe in Ireland, for example, lists 1.5% + €0.25 for standard EEA cards on its pricing page, with higher fees for UK and international cards. On a €50 monthly subscription that is about €1 per payment, a cost that belongs in your product pricing, not in the build budget.

How do the price ranges for the three types compare side by side?

The table below brings the assumptions and results together. It is meant for comparing orders of magnitude and for conversations with vendors, not as a price list. You can recalculate every row with your own assumptions.

Application type	Team (FTE)	Time to production	Person-months	Build cost (before contingency)	What moves the price most	When to choose this type
Internal system	3	3-5 months	9-15	EUR 54,000-131,000	Data migration, number of process exceptions, integrations	The process is unusual or a source of advantage; off-the-shelf tools force workarounds
Customer portal (narrow)	2.5	3 months	7.5	EUR 45,000-65,000	Quality of the source system’s API	You want to test whether customers will self-serve
Customer portal (full)	4	4-6 months	16-24	EUR 96,000-210,000	ERP integration, customer-specific pricing, accessibility (B2C)	Reducing service workload, B2B online sales
SaaS platform 1.0	6	7-10 months	42-60	EUR 253,000-524,000	Multi-tenancy, billing, SSO, enterprise customer demands	A product sold to many customers on subscription

Shared assumptions: senior rate EUR 335-485 per day, 18 billable days per FTE per month. Add a contingency of about 15% to each result, plus the external costs described below.

Two observations. First, the difference between types comes mainly from the number of person-months, not from rates. The rate moves the result by roughly 45% between the bottom and top of the band, while scope moves it several-fold. Negotiating the rate therefore has less effect on the budget than scope discipline. Second, the narrow portal costs less than a third of the full one. If you are not sure customers will adopt a new channel, that difference is the price of testing the hypothesis before a large investment.

What moves the price of a web application up or down?

Six factors account for most of the gap between the bottom and the top of each range. Walk through them with every vendor, because each can be described before you sign.

Integrations. Every system the application exchanges data with is a small project of its own: API analysis, field mapping, error handling, testing against the other side’s test environment. Integrating with a system that has a documented REST API and a sandbox is several times cheaper than with one you can only reach through its database or file exports. Ask the vendor how many days it plans for each integration separately.

Roles and permissions. An application with one type of user is simple. One where the customer has an administrator, a buyer and an accountant, each seeing different data, needs a well-designed permission model and tests for every combination. The number of roles multiplies the number of test cases.

Data and migration. An application that starts with an empty database is cheaper than one that must take over ten years of history. Migration needs data quality analysis, scripts, several trial runs and business decisions about what to do with incomplete records.

Non-functional requirements. Performance under heavy load, high availability, encryption, audit trails, GDPR compliance and, in consumer services, digital accessibility. Each requirement is legitimate, but each costs money, and each should be stated as a number: how many concurrent users, what response time, what maximum acceptable outage.

Interface design. An application built on an existing component library is markedly cheaper than one with a bespoke design system, animations and every screen polished. For an internal system, existing components are usually enough. For a SaaS product competing for customers, the look can be part of the value.

How fast you decide. This is the most overlooked factor. A team waiting a week for an answer about a discount rule is still on the clock. One person on the client side with the authority to make quick scope decisions can shorten a schedule more than an extra developer.

Which costs are missing from the build quote but will appear on your invoices?

A software vendor’s proposal prices the team’s work. Other costs will hit your account too, and it pays to budget for them from the start so the board does not discover them after launch.

• Hosting and cloud infrastructure. Production, test and development environments, databases, backups, monitoring. For a small portal this is in the hundreds or low thousands of euros a month; for a SaaS platform with many customers, more. Ask the vendor for an estimate at your scale, not a generic statement.
• Third-party services. Payment gateway, email and SMS delivery, maps, identity verification, AI services. Most are billed by volume, so they grow with your product’s success.
• Licences. Commercial libraries, error monitoring tools, SSO services and sometimes a licence for the API of the system you integrate with.
• Contingency for change. The 10-20% of build budget mentioned above. It is not a “just in case” buffer but an honest admission that some requirements only become clear after the first demos.
• Post-launch maintenance and evolution. Library and framework updates, security patches, small user-requested changes, monitoring. In our custom software guide we assumed 20% of build cost per year from the second year onwards. Your figure may differ, but plan it as a recurring cost, not a one-off. Support models are described in our article on why software maintenance matters as much as development.
• Your own people’s time. A product owner, domain experts in workshops, acceptance testing. Not a line on the vendor’s invoice, but a real project cost.

A simple test of any proposal: if the vendor mentions none of these items, ask whether it simply did not price them or assumes they are your problem.

Fixed price or time and materials: which billing model suits a web application?

The billing model changes more than how you pay. It decides who carries the risk of unknown scope and how much you pay for that. ARDURA Consulting delivers projects in both models, and in practice the rule is simple.

Fixed price makes sense when the scope is described at a level that can be verified at acceptance: a feature list with acceptance criteria, wireframes of key screens, integration descriptions naming specific APIs. That description usually comes out of a discovery phase. A fixed price on such a scope gives the board predictability and the vendor clear criteria. The price is less flexibility: every change becomes a change request.

Time and materials makes sense when the scope will become clear during the build, which is normal for new products. You pay for time actually worked and keep control through a budget per stage, a review after every sprint and the right to stop. This model is cheaper under uncertain scope, because the vendor does not have to price in a large contingency, but it needs active involvement on your side.

The most common mistake is combining agile delivery with a fixed-price contract on a vague specification. It ends in disputes about what was “in scope”, and both sides are right by their own reading. A middle path is a fixed price for discovery and the first stage, then time and materials with a budget cap for later stages. A comparison of the models and how they split risk is in our article on team subscription, time and materials and fixed price.

How can you check whether a software vendor’s proposal is realistic?

A realistic proposal is one whose arithmetic you can reproduce. The questions below reduce every proposal to a common denominator and expose assumptions the vendor left unsaid.

1. What is the team composition and allocation? Ask for the list of roles with the percentage of time for each person in each stage. No QA, DevOps or analyst is not a saving; it shifts work to you.
2. How many person-months do you assume, at what rates? Multiply and check that you get the quoted total. If not, ask about the difference.
3. What exactly does each integration cover? Direction of data flow, frequency, error handling, the other side’s test environment, who provides API access.
4. How do you test, and who owns acceptance testing? Automated tests of key journeys should be part of the build, not an option.
5. What contingency does the price include, and what happens when it runs out? In fixed price it is in the price; in time and materials it should be visible.
6. Who owns the code, and from when? Assignment of intellectual property rights, repository access from day one, documentation.
7. What does handover look like if we end the engagement? Documentation, a transition period, support for a new team.
8. Which external costs do you expect? Hosting, licences, volume-based paid services.

You can also run the arithmetic backwards to sanity-check a proposal that has no breakdown. Back to the operations director from the introduction. The €45,000 proposal, divided by the cost of a senior person-month (EUR 6,030-8,730), buys about 5-7 person-months. With four people that is less than two months. A full portal with a two-way ERP integration in two months is unlikely, so either the proposal assumes a much narrower scope than she thinks, or a mostly junior team, or it leaves out items such as testing and the integration. The €340,000 proposal buys 39-56 person-months, a scope closer to a platform than a portal; it is worth asking what is in it beyond the needs of version one. The €130,000 proposal sits inside the full-portal range, which does not make it good. It only means its arithmetic is plausible and the rest of the list is worth checking.

The answers to these questions tell you more than any company presentation. A vendor who answers concretely and with numbers usually runs projects the same way.

Which warning signs in a proposal should stop you from signing?

A few patterns recur in proposals that later turn into expensive problems. None of them necessarily means bad faith, but each needs an explanation before you sign.

• A price with no breakdown. One figure for “customer portal” with no roles, time or scope. You cannot compare it or price changes against it.
• A fixed price on a scope described in one paragraph. Either the price carries a very large contingency, or the vendor intends to argue every feature with you at acceptance.
• A schedule with no discovery phase. A team that starts coding in week one without analysing integrations and data will find the problems in month three, when they are expensive.
• No testing in the quote, or testing “on the client side”. That shifts cost and risk to you.
• Code kept in the vendor’s repository until the end of the project. Without access to the code you cannot see what is being built and cannot switch vendors.
• IP passes only after full payment. A common and legitimate clause, but combined with no code access it gives the vendor a strong hand in a dispute.
• A price well below the arithmetic. If the proposal assumes four people for five months and the total implies a rate at which seniors cannot be hired, ask who will actually work on the project.

If the project is already running and you see these signs in practice rather than on paper, that is a different problem: you need an assessment of the code and a recovery plan, not another proposal.

How can you reduce the cost of a web application without damaging the product?

The savings that work concern scope, not rates. Senior rates differ between vendors by tens of percent; the scope of a first version can differ several-fold. These are the levers that work.

Start with discovery. A short analysis phase costs a fraction of the build and lets you remove features nobody needs and spot integrations that would otherwise surprise you in month three. At ARDURA, discovery takes 1-2 weeks and ends with a description of scope and architecture. What this stage is and what it should deliver is explained in our glossary entry on the product discovery process.

Cut to one user journey. The first version of a portal does not need to cover every scenario. If 80% of customer contacts with your service team concern order status and invoices, start there. Add the rest when the data shows customers are using it.

Buy rather than build where there is no advantage. Sign-in, notifications, payments, search, document generation: ready-made services exist for all of these. Building them from scratch rarely pays.

An existing component library instead of bespoke design. For an internal system this saves weeks of designer and frontend developer time with no visible loss for users.

Fast decisions. Appoint one person with authority over scope and give them time for the project. It costs nothing and shortens the schedule.

What not to cut: automated tests of key journeys, a test environment and integration documentation. Savings on those come back with interest in the first year of maintenance.

How do you move from a price range to a concrete quote?

The ranges in this article serve one purpose: so that you know whether you are discussing a €60,000 project or a €500,000 one before you invite vendors to the table. A concrete quote takes three steps.

The first step is a quick estimate for your type of product. Our MVP cost calculator shows an indicative range, timeline and team for a web app, mobile app, SaaS or marketplace in seconds. It does not know your integrations or data, but it gives you a reference point.

The second step is writing down what the calculator does not know: the systems to integrate, with a note on whether each has an API, the number of user roles, the data to migrate and the non-functional requirements stated as numbers. That list is half of a good RFP.

The third step is discovery, which turns the range into a quote broken down by role, person-month and stage. After it, you can choose a billing model deliberately rather than blindly.

If you want to go through these steps with us, the software development team at ARDURA Consulting will run discovery and produce a quote with the arithmetic in plain view: roles, time, rates from our published rate card and a contingency you can check. You will find more articles on planning and building software in our software development hub.