€15k–€1M Software Cost Benchmarks and WBS Template for Managers

A small MVP typically costs €15,000–€50,000, a production mobile app €40,000–€200,000, a full web platform €50,000–€250,000, and an enterprise system €100,000 to well over €1 million. AI-driven projects usually sit higher still, because data preparation and inference costs stack on top of conventional development. These bands only hold if scope, complexity, and compliance requirements are clearly defined; the fix is always the same: run a short discovery phase, then build the estimate from a work breakdown structure rather than a gut-feel quote.

TL;DR:

• Small MVPs usually cost between €15,000 and €50,000, with timelines of six to twelve weeks and a small team of two to four people.
• Larger projects like enterprise platforms can exceed €1 million, involving longer timelines of over a year and larger teams of eight or more.
• Data preparation and inference efforts in AI projects often add 40–60% to the total cost, making AI features significantly more expensive than conventional modules.
• Proper estimation requires a detailed work breakdown structure, role-based effort analysis, and explicit inclusion of third-party, maintenance, and contingency costs.
• Using multiple estimation methods—such as parametric models, expert judgment, and functional sizing—and validating them against internal data improves accuracy and reduces budget overruns.

Table of Contents

• What Are Realistic Cost Ranges by Project Type?
• What Actually Makes Up a Software Development Quote?
• Which Estimation Method Should You Trust?
• How Do You Build a Verifiable Cost Estimate?
• Why Do Software Projects Go Over Budget?
• Fixed Price, Time and Materials, or Something in Between?
• A Worked Example: Costing an MVP From Scratch
• How Engineering-First Delivery Reduces Estimation Risk
• Copy This Checklist Before You Request a Quote
• What I’ve Learned Watching Estimates Fall Apart
• Plan Your Project With a WBS-Based Estimate, Not a Guess
• Sources
• FAQ

What Are Realistic Cost Ranges by Project Type?

Every supplier quote should be checked against a benchmark, and the benchmark should reflect the type of software you are actually building, not a generic “app” category that hides wildly different levels of complexity.

An MVP with one or two core user flows, basic authentication, and no third-party integrations usually lands between €15,000 and €50,000. Expect a small team (two to four people) and a build window of six to twelve weeks. A production-grade mobile app, with push notifications, offline handling, and app-store compliance work, runs €40,000 to €200,000 over three to six months, often with five to seven contributors including design and QA.

A custom web application, think internal tooling, a customer portal, or a SaaS front end, tends to fall between €50,000 and €250,000, depending on how many roles and integrations it touches. Enterprise platforms, which typically involve legacy integration, multi-tenant architecture, and formal security review, start around €100,000 and can exceed €1 million once you add regulatory audit trails, single sign-on, and high-availability infrastructure. Timelines here stretch from six months to well over a year, with teams of eight or more.

AI and machine-learning projects break the usual pattern. Budget for data labelling and preparation to consume 40–60% of total effort, plus ongoing inferencing and monitoring costs that persist long after launch, according to guidance on software development costs. That single factor is why an AI feature that looks like “just another module” on a proposal often ends up costing double a comparable conventional feature.

• MVP: €15,000–€50,000, six to twelve weeks, two to four people
• Mobile app (production): €40,000–€200,000, three to six months, five to seven people
• Web application: €50,000–€250,000, three to eight months, four to eight people
• Enterprise platform: €100,000–€1,000,000+, six months to two years, eight-plus people
• AI/ML project: conventional range plus 40–60% additional effort for data and inference work

Regional rate differences rarely tell the whole story. A lower hourly rate in one market can produce a higher total project cost once you factor in extra revision cycles, weaker documentation, and slower ramp-up on unfamiliar codebases. A guarded rule worth applying to every quote: a cheaper rate does not guarantee a cheaper project, so weigh output quality and rework risk against the headline number, as noted in guidance on preparing a software quote.

Freelance and boutique-team benchmarks in the Italian market broadly track these bands too, with some variation depending on whether the team is fully in-house or distributed, per FreelanceDEV.it’s cost overview.

What Actually Makes Up a Software Development Quote?

A quote that lists only “development hours” is incomplete. Reading a proposal line by line means checking for five categories of cost, and flagging anything that is missing rather than assuming it is bundled in.

Role-level effort drives most of the budget, and the mix matters as much as the total hours. A project manager typically bills €40–€80 per hour, a senior developer €50–€110, a mid-level developer €35–€70, a QA engineer €30–€60, a DevOps specialist €50–€100, and a UX/UI designer €35–€75. Rates vary by region and specialism, but the ratio between roles should stay roughly consistent: a quote stacked almost entirely with senior developer hours and no QA or design allocation is a red flag, not a bargain.

Non-development costs get overlooked constantly. Third-party licences (payment gateways, mapping APIs, analytics platforms), cloud hosting, and integration fees for external systems can add 10–20% to a project’s direct cost, and they rarely appear on a first-pass estimate unless you ask for them explicitly.

Recurring costs are the category most quotes skip entirely, because they fall outside the “delivery” scope suppliers are pricing. Maintenance typically runs 15–20% of the initial development cost every year, a figure consistent across multiple industry sources on software development costs. Security monitoring, uptime alerting, and ongoing support add further recurring spend on top of that baseline.

• PM and coordination: typically 10–15% of total project hours
• QA and testing: typically 15–20% of development hours
• DevOps and infrastructure setup: 10–15% of total effort, higher for cloud-native or multi-tenant systems
• Third-party licences and APIs: variable, but budget 5–15% of total cost
• Annual maintenance: 15–20% of the original development cost, every year post-launch

The uncomfortable truth for most budget-holders is that 60–70% of a solution’s total lifecycle cost happens after the initial launch, not before it, according to the same SectorPunk analysis. Treat the initial build price as the down payment, not the total.

Which Estimation Method Should You Trust?

No single technique is reliable on its own; the discipline is in knowing which method fits which stage of a project, then checking one against another.

Expert judgement relies on experienced engineers reviewing a scope and giving a gut estimate grounded in past projects. It is fast and useful early on, but it carries individual bias and tends to underestimate integration complexity. Analogous estimation compares the new project to a similar past one and scales the numbers. It works well when you have a genuinely comparable reference project, but poorly when the new build has novel architecture or an unfamiliar domain.

Parametric estimation uses historical data (cost per feature, cost per function point) to calculate effort mathematically. It is the most defensible method when you have solid internal data, and it is the one method that scales cleanly as scope grows or shrinks.

Functional sizing, using COSMIC or function points, measures the software’s actual functional size independently of the technology used to build it. This differs from story points, which are relative and team-specific: a five-point story on one team might be an eight-point story on another. COSMIC gives you a standardised, comparable unit that supports genuine parametric estimation across teams and even across suppliers, as detailed on COSMIC’s functional sizing resources. Research into estimation methods and their biases, including work presented at the IWSM/Mensura conference, backs the case for combining functional sizing with structured expert review rather than relying on either alone.

• Expert judgement: fast, cheap, useful for early sanity checks; weak on novel scope
• Analogous estimation: reliable with a genuinely comparable past project; weak without one
• Parametric estimation: strong with good historical data; needs that data to exist first
• COSMIC/function points: standardised, comparable across teams and suppliers; requires more upfront analysis than story points

Pro Tip: Never rely on a single method for a fixed-price commitment. Run a parametric estimate from historical data, then have a senior engineer sanity-check it against expert judgement before it goes into a contract. Triangulating the two methods against recent internal metrics is one of the more reliable ways to land close to the actual number, per Harvest’s estimation guidance.

How Do You Build a Verifiable Cost Estimate?

A defendable estimate follows a repeatable sequence rather than a single inspired guess, and each step produces something you can hand to a stakeholder or a supplier for scrutiny.

1. Define scope and acceptance criteria first. Write down what “done” looks like for every major feature before anyone estimates a single hour. Vague requirements are the single biggest cause of estimate drift.
2. Build a work breakdown structure (WBS). Split the project into features, then into tasks small enough to estimate individually, typically no larger than three to five days of work each. A good WBS, grounded in clear requirements, is the foundation every reliable quote depends on, according to Matech Studio’s guidance on software quotes.
3. Size each item. Use relative sizing (story points) for agile internal planning, or function points/COSMIC when you need a standardised, supplier-comparable measure.
4. Convert size to hours. Apply historical velocity or productivity metrics from past projects. If you have no internal history yet, use published benchmarks as a starting point, then recalibrate after the first sprint or milestone.
5. Apply role-based hourly rates to each task, using the rate bands from the cost-breakdown section above.
6. Add third-party and infrastructure costs identified during the WBS exercise, not estimated separately afterwards.
7. Layer in contingency, QA allocation, and a maintenance line for the post-launch period.
8. Document every assumption, risk, and re-estimate trigger so the estimate can be defended and revisited when scope inevitably shifts.

Historical data is what separates a defensible estimate from an educated guess. If your organisation has delivered similar projects before, mining that data for actual hours-per-feature and actual defect rates gives your parametric model real teeth. A tool like Harvest or a comparable time-tracking platform helps close that loop by capturing burn rate in real time, so the next estimate is calibrated against reality rather than optimism.

• Keep the WBS granular enough that no single task exceeds roughly 5% of total project hours.
• Re-estimate at every major milestone, not just at the start.
• Store assumptions alongside the estimate itself, so a scope change automatically flags which numbers need revisiting.
• Track actuals against the estimate weekly; drift caught early is cheap to correct, drift caught at delivery is not.

Productivity-focused tooling, including AI-assisted workflows covered in AmmarAI’s guidance for agencies, can also speed up the estimation cycle itself by automating parts of task breakdown and effort logging, freeing senior engineers to focus on the judgement calls that actually need their attention.

Why Do Software Projects Go Over Budget?

Average cost overruns on technology projects sit around 45%, and that figure climbs to roughly 66% on projects over $15 million, according to Harvest’s research on project cost estimation. Those aren’t outliers; they are the norm when contingency is treated as an afterthought rather than a planning input.

Most overruns trace back to a short, predictable list of blind spots: third-party integration work that turns out harder than expected, data migration from a legacy system nobody fully documented, internal project management overhead that never made it into the original scope, compliance retrofitting bolted on after a security review, and UI rework triggered by stakeholder feedback that arrives after development has already started.

A sensible baseline contingency is 10–25% of total estimated cost for a conventional project, applied as a visible line item rather than buried inside padded task estimates. Regulated sectors need more headroom: compliance work for standards like SOC 2, HIPAA, or PCI can add 10–25% or more on top of the base budget, depending on how many controls need to be built, audited, and evidenced, per SectorPunk’s cost analysis.

• Integration with existing systems (APIs that don’t behave as documented)
• Data migration and cleansing from legacy databases
• Internal PM and stakeholder coordination time
• Compliance and security retrofitting discovered mid-build
• UI/UX rework following the first real usability review

Present contingency to stakeholders as a named, separate figure, not a hidden buffer folded into hourly rates. A quote that says “€180,000 development plus 15% contingency (€27,000)” is far easier to trust, and to negotiate, than one that simply says “€207,000.”

Fixed Price, Time and Materials, or Something in Between?

The contract model you choose allocates risk between you and the supplier, and picking the wrong one for the situation is what turns a reasonable estimate into a dispute.

Fixed price works well when scope is genuinely stable and well understood, typically after a discovery phase or a proof-of-concept has already de-risked the unknowns. It gives budget certainty, but it needs safeguards: a detailed WBS attached to the contract, a defined change-request process with pre-agreed rates, and acceptance criteria written into each milestone. Fixed price without a real WBS behind it is simply a guess wearing a contract.

Time and materials (T&M) suits projects with evolving requirements, discovery-stage work, or anything genuinely novel. It reduces the supplier’s incentive to cut corners on scope, but it needs governance to avoid open-ended spend: a monthly or sprint-level cap, mandatory burn-rate reporting, and a defined escalation point if projected hours start drifting from the estimate.

Hybrid and phased models often give you the best of both: a fixed-price discovery or proof-of-concept phase, followed by a fixed-price or capped-T&M build phase once the unknowns from discovery have been resolved. This is the model worth defaulting to for anything above roughly €80,000–€100,000 in projected spend, because it converts the riskiest part of the estimate (early scope uncertainty) into a small, contained cost before the big commitment.

• Fixed price: best for stable, well-documented scope; requires a WBS-backed contract and formal change control
• Time and materials: best for evolving or exploratory work; requires caps, reporting cadence, and escalation triggers
• Phased/hybrid: best for larger or higher-risk projects; de-risks the fixed-price commitment with a paid discovery phase first
• Block-hour arrangements, similar to the pre-paid model described by 121 Group, offer a middle ground for ongoing advisory or senior-level input without a full T&M contract

A Worked Example: Costing an MVP From Scratch

Take a straightforward MVP: a customer-facing web app with authentication, a core workflow, an admin panel, and a payment integration. Building the estimate from a WBS rather than a single lump figure is what makes the number defensible.

1. Discovery and requirements definition: 40 hours (PM + senior developer)
2. Authentication and user management: 60 hours (mid developer)
3. Core workflow (main feature set): 180 hours (senior + mid developer)
4. Admin panel: 90 hours (mid developer)
5. Payment integration: 50 hours (senior developer)
6. QA and testing across all modules: 90 hours (QA engineer)
7. DevOps setup and deployment pipeline: 40 hours (DevOps specialist)
8. Project management across the build: 60 hours (PM)

That total sits comfortably inside the €15,000–€50,000 MVP band described earlier, but the WBS is what makes it defensible against a supplier’s competing quote. Change one variable, add a second payment provider, or bring in a compliance requirement such as PCI-DSS for card data, and the number moves fast: expect the QA and DevOps lines to grow disproportionately, and expect contingency to climb from 15% towards 20–25% once regulatory testing enters the picture.

How Engineering-First Delivery Reduces Estimation Risk

The biggest source of hidden cost on a software project isn’t a missed line item; it’s rework caused by decisions made without the people who actually have to build the fix. Our engineering-first delivery model removes the account-manager layer, enabling clients to collaborate directly with the engineers who design and build the system from discovery through deployment.

That structure matters for estimation specifically. A change request or a technical constraint gets surfaced by the engineer who understands it, not relayed through an intermediary who has to check first and reply later. Every engagement includes peer-reviewed code, targeted testing, and production observability, which catches defects and architectural drift before they turn into the unbudgeted rework that inflates so many project totals.

• Direct engineer access shortens the feedback loop on scope questions and change requests
• Peer review and targeted testing catch defects before they become post-launch fixes
• Production monitoring and transparent reporting give stakeholders real visibility into burn rate against the original estimate
• Discovery-phase engagement produces the WBS-based numbers a fixed-price or hybrid contract actually needs

For decision-makers comparing quotes, that combination, direct technical access plus documented, reviewable delivery, is what separates an estimate that holds up from one that quietly drifts by 20% before the first milestone.

Copy This Checklist Before You Request a Quote

A request-for-estimate (RFE) that omits key fields guarantees suppliers will quote against different assumptions, making their numbers impossible to compare fairly.

Mandatory RFE fields: scope description with user stories or use cases, acceptance criteria per feature, non-functional requirements (performance, security, compliance standards), a list of required third-party interfaces and integrations, and a target timeline with any hard deadlines.

Assumptions every supplier must disclose: contingency percentage applied, third-party licence costs included or excluded, post-launch maintenance terms, and anything explicitly out of scope.

1. Request the WBS behind the number, not just a total
2. Ask which estimation method was used (expert judgement, parametric, functional sizing)
3. Confirm the contingency percentage and what triggers a re-estimate
4. Check that QA, DevOps, and PM hours appear as distinct line items
5. Verify maintenance and support costs are quoted separately from build cost

• Does the quote separate development, QA, DevOps, and PM hours?
• Are third-party costs itemised rather than bundled?
• Is contingency stated explicitly, with a percentage?
• Does the supplier disclose exclusions and assumptions in writing?

What I’ve Learned Watching Estimates Fall Apart

The estimates that fail almost never fail on the hourly rate. They fail because someone signed a fixed-price contract against a scope that was still, quietly, being negotiated in someone’s head. The fix isn’t a better spreadsheet; it’s a paid discovery week before the big number gets written down. It costs a fraction of the project and it tells you, honestly, whether the scope in front of you is real.

— Pepe F.

Plan Your Project With a WBS-Based Estimate, Not a Guess

Most software quotes are built backwards: a headline price first, a justification for it second. A short discovery phase produces a work breakdown structure, and the quote that follows is built line by line from that WBS, with third-party costs, contingency, and maintenance stated separately rather than buried.

That structure matters most once the project is underway. Because clients work directly with the engineers delivering the system, scope questions get resolved quickly, and time and materials engagements can come with defined caps and regular reporting rather than open-ended billing. The result is fewer surprises between the estimate you signed off and the invoice you actually receive.

If you are weighing up a fixed-price, time-and-materials, or phased contract for an upcoming build, the sensible next step is a short discovery session that turns your rough scope into a real, WBS-based estimate. Browse Vicedomini Softworks’ services to see how discovery, quoting, and ongoing support fit together, or review past case studies to see how similar projects were scoped and delivered.

Sources

For readers who want to go deeper on methodology, COSMIC’s functional sizing standard is the reference point for standardised, technology-independent sizing. The IWSM/Mensura conference paper covers documented biases in estimation methods, useful for validating your chosen approach. Harvest’s guide to estimating software project cost provides the overrun statistics cited throughout this article, alongside practical time-tracking advice. SectorPunk’s cost breakdown and Matech Studio’s guide to software quotes both offer detailed lifecycle and quote-structuring guidance worth cross-referencing against your own numbers.

• COSMIC functional sizing
• Costi di sviluppo software 2026: guida | SectorPunk

FAQ

How Much Does Custom Software Development Cost?

Costs range from roughly €15,000 for a small MVP to over €1 million for a complex enterprise platform, with mobile apps typically falling between €40,000 and €200,000 and web applications between €50,000 and €250,000. The exact figure depends on scope clarity, integrations, and compliance requirements.

What Is the Best Way to Estimate Software Costs?

Triangulate methods rather than relying on one: build a work breakdown structure, size each task using historical data or functional sizing (COSMIC), convert size to hours using past velocity, then have a senior engineer sanity-check the result against expert judgement.

Is Fixed Price or Time and Materials Better for a Software Project?

Fixed price works best when scope is stable and backed by a detailed WBS; time and materials suits evolving or exploratory scope but needs caps and regular reporting to control spend. A phased approach, fixed-price discovery followed by a capped build phase, reduces risk on most projects above roughly €80,000.

Why Do Software Projects Cost More Than the Original Quote?

Overruns typically come from a short list of recurring blind spots: underestimated integrations, undocumented data migration, uncounted internal PM time, and compliance work discovered mid-build.