If you landed here looking for a price for your .NET application, let me save you time: nobody serious will give you a closed number over email. I won''t either. But I can do something more useful — explain how a custom software budget is actually built in 2026, what variables move it, and what ranges are realistic for the kind of project you have in mind.
I''ve been building enterprise software in .NET for over 18 years, the last several as a senior freelancer. I''ve seen €4,500 projects ship without surprises and €80,000 proposals that fell short. The difference is rarely about who does the work. It''s almost always about how scope is defined, how risk is managed, and what expectations the client brings to the first call. I''ll walk you through how I see it after many projects in industry, accounting, logistics and public sector.
Why nobody gives you a closed price over email
Agencies that quote wide ranges — "between €5,000 and €70,000" — aren''t lying. Without an hour of conversation they can''t do anything else. A custom application is like renovating a house: if you ask me how much a renovation costs without knowing square meters, materials, or whether walls need to come down, my answer can only be a useless wide range.
A serious budget is built backwards. First we understand what problem you''re solving, then which use cases are critical, then which integrations exist, and only then a number appears. If someone closes a price over email without that conversation, either they''re selling templates with the name changed, or you''ll get a second invoice when the first "unforeseen issue" pops up. And unforeseen issues in software always pop up — the question is whether they were budgeted or not.
The 5 variables that move the budget by 300%
These are the levers that really change a budget. I''ve seen the same project go from €15,000 to €45,000 by moving just two of these. If you have these five clear, you''ll understand why you''re being charged what you''re being charged — and you''ll be able to negotiate with judgment instead of haggling on instinct.
1. Integrations with existing systems
An app that lives alone is cheap. An app that has to talk to your 12-year-old ERP, your payment gateway, your Active Directory and a shipping service gets expensive fast. Each integration adds between 8 and 40 hours, and sometimes more if the other system''s documentation is bad or non-existent. If your API has a clean Swagger, two hours. If your ERP only exposes XML over SOAP with weird auth nobody remembers how it works, prepare for a week of detective work.
The most expensive work I''ve done in my career wasn''t developing new features, it was figuring out how an undocumented legacy system worked so I could connect it to something modern. That archaeology work is always underestimated in budgets, and that''s where most projects go off the rails.
2. Data volume and expected performance
An internal app for 20 people doesn''t have the same requirements as a portal with 5,000 concurrent sessions. The first you build with SQL Server, Razor Pages and a €30/month App Service. The second forces you to think about distributed cache, database replication, load balancers and CDN. Building one version and then "scaling it" is almost always more expensive than sizing it right from the start.
The number of concurrent users and the data volume you''ll store are the two questions that change a budget the most. Managing 5,000 invoices a year isn''t the same as managing 5 million. If you don''t have those numbers, the first thing we''ll do is estimate them together before putting a price on anything.
3. UX design and branding
Some clients are happy with a decent Bootstrap. Others want every screen designed down to the pixel because their product sells on experience. The first approach saves between 20 and 40 % of the budget. The second is justified when the app is a direct sales channel or when you compete with companies that have polished products.
My honest recommendation: if it''s an internal tool, spend on UX just enough so your team doesn''t hate you. If it''s customer-facing, hire a designer from day one or accept that the first version will need to be redone. I''ve seen too many projects launched with "we''ll add a designer later" that ended with the technical team improvising interfaces two weeks after going live.
4. Permissions, roles and multitenancy
Building an app where "everyone sees everything" is fast. Adding a role system with granular permissions, real multitenancy (each client only sees their data), and access auditing can double the scope of the security layer. And multitenancy is one of those decisions that''s much cheaper if you take it on day one than if you add it in year two when the database has 200,000 mixed records.
One concrete question that will clarify a lot: are you going to sell this application to several clients or is it just for your company? If the answer is "just for us, for now", assume that at some point you''ll want to sell or license it, and prepare the data model so that day isn''t a nightmare.
5. Regulatory compliance
An app that only stores internal commercial data doesn''t have the same requirements as one handling medical, financial or minors'' data. GDPR always applies, but there are sectors that add additional layers — Spanish LOPDGDD, PCI-DSS if you touch payments, ENS if you sell to public administration. Complying with these well isn''t just adding a cookie check, it''s designing the architecture so compliance is a natural consequence of the code, not a patch.
If your sector is regulated, say so in the first call. It''s one of the few things that can really multiply a budget, and it''s much better to know it from the start than to discover it in the audit before deployment.
Senior freelance hourly rate in Spain in 2026
Malt''s 2026 barometer for Spain puts the average senior C# developer rate around €335 per day, with upper tiers above €500. That translates to about €42-65 per hour for truly senior profiles, and higher for specific roles like cloud architecture or tech lead. Those are market averages — I move within the range with adjustments based on project type and engagement model.
What hardly anyone explains is that the hourly rate says less than it seems. An expensive senior who delivers in three weeks what a junior would do in three months is cheaper in absolute terms. The right question isn''t "what does the hour cost", it''s "what does this project cost delivered, tested and working". That''s why I almost always prefer fixed price by scope: it''s predictable for you and honest for me.
Indicative table: project type and realistic range
These ranges assume a senior profile, well-defined scope and reasonable timelines. They can be lower if scope is very tight or if you bring design and specification yourself. They can be higher if there are complex integrations, strict regulation, or high usage peaks.
- Simple internal tool (replacing spreadsheets, task management, forms + lists with basic permissions): €4,000 - €8,000 and 3 to 6 weeks of work.
- Client portal or intranet (login, profiles, data panels, documentation downloads, integration with existing CRM or ERP): €9,000 - €18,000 and 6 to 10 weeks.
- Lightweight custom CRM or ERP (managing clients, products, quotes, invoices, reports): €18,000 - €40,000 and 10 to 16 weeks.
- Multitenant SaaS application (with subscriptions, recurring billing, admin panel, first cloud deployment, monitoring): €35,000 - €70,000 and 4 to 7 months.
- Integration or automation between systems (no new frontend, just processes and APIs): €5,000 - €20,000 depending on complexity and number of systems involved.
If your project is above these ranges, it doesn''t mean the developer is inflating the price. You might be asking for a product, not a tool. If it''s below, be suspicious. When a proposal is very low, what''s usually being saved is testing, documentation, automated deployment or experience — and all of that gets paid for later.
How to reduce cost without sacrificing quality
If your budget is tight, there are smart ways to adapt and ways that will cost you dearly mid-term. These are the ones I recommend when a client comes with less money than their original idea needs.
Cut scope, not quality. Better to deliver three solid, well-tested features than ten half-baked ones. Launch an honest 1.0 that covers critical cases and come back in three months with 1.1. This is also the best way to learn from real users before building what you think they need.
Postpone multitenancy if you only have one client. If the app will start being yours and only yours, building the whole multitenancy apparatus from day one is overengineering. Leave it prepared at the architectural level and build it when the second client appears.
Avoid SPAs if you don''t need them. A Razor Pages app with some jQuery or HTMX covers 90 % of internal applications. Every time a client tells me "I want it like a modern Gmail-style web", my first question is why — because often what they need is a functional tool, not a React SPA that costs double in development and the same in maintenance.
Leverage what exists. If Stripe solves payments, don''t build a billing system from scratch. If Auth0 or Microsoft Entra solve login, don''t write your own Identity Server. Each component you delegate to a proven service saves 40 to 200 hours of development and the same in future maintenance.
The factor almost nobody explains: maintenance cost
Development price is just the first invoice. A custom application needs maintenance: security patches, framework updates, incident support, small changes the team requests once they start using it. As a rule of thumb, budget 15 to 25 % of development cost per year for healthy maintenance.
That''s not because your app is poorly built. It''s because .NET evolves, dependencies update, new vulnerabilities appear, and your business keeps moving. An app that isn''t maintained for two years stops being an asset and starts being a risk. I''ve seen this many times with clients who come "because the app they built years ago is starting to give problems". 80 % of those problems would have been avoided with moderate and regular maintenance.
If you''re going to hire someone to build, ask about their post-delivery maintenance model too. A good developer will offer you at least 30 days of free support after delivery and a reasonable monthly pack afterward. If they only want to close development and disappear, that''s a red flag.