Custom Software Development Cost (2026): Ranges by Project Type, Team Model and Region

Custom software development typically costs $14,000 to $320,000 at Eastern European rates and $32,000 to $640,000 with a US onshore team, depending on whether you are building a small internal tool or a full custom ERP. Behind every one of those numbers is the same formula: the hours your scope needs, multiplied by the hourly rate of the team that builds it.

We are engineers who build these systems: portals, internal tools, SaaS products, integrations and .NET modernizations. This guide shows how we would size a project before quoting it. The ranges below are planning ranges and market rates, not a quote and not our price list. Use them to set a budget, compare proposals and spot an estimate that is far too low or far too high.

Cost at a glance

Each row multiplies a typical effort range by two rate bands: about $35 to $80 per hour for Eastern Europe and $80 to $160 per hour for US onshore teams.

Calendar time assumes a team of two to four engineers with about 30 productive hours each per week. A bigger team shortens the calendar, but not in a straight line, because coordination costs hours too.

The type of project sets the starting range. For deeper breakdowns of individual types, see our guides to custom CRM development cost, custom ERP development cost, SaaS development cost, AI development cost and web application development cost.

What drives the cost

Two projects with the same number of screens can differ in cost by a factor of three. These are the drivers we look at first.

1. Number of user roles and permissions. A tool used by one team with one role is simple. Add customers, partners, managers and admins, each seeing different data, and every screen and API endpoint needs access rules and tests for each role.

2. Workflow depth. A form that saves a record is cheap. A record that moves through statuses, approvals, deadlines and escalations, with an audit trail, is where most business logic lives, and where most of the hours go.

3. Integrations. Each external system adds mapping, authentication, error handling, retries and monitoring. A clean modern API might take 60 hours; an old SOAP service or a system with rate limits and inconsistent data can take three times that.

4. Data migration. Moving years of data out of spreadsheets or a legacy system means cleaning it, mapping it and running trial imports until the numbers match. It is often underestimated because nobody sees it in a demo.

5. Non-functional requirements. High traffic, strict uptime, audit logging, data residency or compliance work such as GDPR or HIPAA all add architecture and testing time that does not show up as features.

6. Existing code. Building on top of a system that has no tests or documentation costs more than starting clean, at least at first. Sometimes a partial rebuild is the cheaper path, which is the call we made on the AgTech project described below.

7. Team composition and rate. A senior engineer at a higher rate who makes good decisions early often costs less in total than a cheaper team that needs rework. Rate is only half the formula.

Try the drivers on your own scope: pick the modules your system needs and the rate band you are comparing.

Cost by component

These are the same modules as in the estimator, with costs at both rate bands. They help you read a vendor proposal line by line.

The preselected scope in the estimator, a mid-size business application with one integration, comes to 850 to 2,150 hours. That is about $29,750 to $172,000 at Eastern European rates and $68,000 to $344,000 at US onshore rates.

Fixed price, time and materials or a dedicated team

How you contract the work changes the price as much as where the team sits. Each model moves risk to a different side of the table.

Fixed price. You agree on scope, price and deadline up front. It is predictable, and it works well for MVPs and defined rebuilds. The catch: the vendor carries the risk of anything unclear, so a sensible quote includes a buffer, and every change after signing becomes a change request. If your scope is still forming, you pay for that uncertainty either way.

Time and materials. You pay for hours actually worked, usually in sprints with a running estimate. Priorities can change as you learn, and you do not pay for a risk buffer. In return, you need someone on your side who owns priorities and reviews progress every week, or the budget drifts.

Dedicated team. A stable group of engineers, often with QA and a project manager, works only on your product and is billed monthly. It suits products with a roadmap measured in months or years, because knowledge stays in the team and the monthly cost is easy to plan. It is the wrong choice for a one-off project with a clear end.

In our experience, the honest answer is often a mix: a fixed-price discovery phase, then time and materials or a dedicated team for the build once the scope is written down.

Rates by region

Hourly rates are the second half of the formula. 2026 outsourcing rate surveys put Eastern Europe at about $35 to $80 per hour, North America at $80 to $180 or more, and South and Southeast Asia at about $25 to $60. 2025 rate surveys estimate that offshore hiring can be 40-70% cheaper than an equivalent hire in the US or Western Europe. The three bands we use in this guide are rounded from those surveys: Eastern Europe $35-80, US onshore $80-160 and South Asia $20-50 per hour.

If you are comparing outsourcing with hiring, the US Bureau of Labor Statistics reports a median annual wage of $135,980 for software developers in May 2025. Divided by 2,080 working hours, that is about $65 per hour in wages alone. Benefits, payroll taxes, equipment, recruiting and management come on top, and you carry the cost of idle time between projects.

Within a region, seniority moves the rate more than the city does. A team of one senior engineer and two mid-level engineers is a common shape for a mid-size project; an all-senior team costs more per hour but usually needs fewer of them.

Running costs after launch

The build is not the last invoice. Plan for three kinds of running cost:

• Maintenance. Bug fixes, security patches, framework and library updates, and small changes. A common industry rule of thumb puts this at roughly 15-20% of the original development cost per year. Treat it as a planning number, not a law: a stable internal tool can need less, and an actively used product with frequent changes more.
• Hosting and infrastructure. Cloud servers, databases, storage, backups and monitoring. The bill depends on traffic, data volume and uptime requirements, so get it sized during discovery rather than guessing.
• Third-party services. Email delivery, SSO or identity providers, maps, payments, SMS and paid APIs, often priced per user or per transaction.

Framework support windows matter too. A system built today on a long-term support version of .NET or a current frontend framework will need an upgrade within a few years. Our guide to migrating from .NET Framework to .NET 10 shows what that work looks like when it is left too long.

How to get an accurate estimate

1. Write down who uses the system. List every user role and what each one needs to see and do.
2. Describe the three to five key workflows. For each, note the steps, statuses, approvals and what happens when something goes wrong.
3. List integrations and data. Name every system you need to connect, whether it has an API, and how much historical data you will migrate.
4. Separate must-haves from later. A clear first release is the single biggest lever on cost and time.
5. Ask for ranges per module. A proposal that shows hours per component lets you compare vendors line by line and cut scope where it makes sense.
6. Add contingency. Keep 15-25% on top of the estimate for unknowns. Every project finds some.
7. Run a short discovery phase. One to three weeks of workshops and a written specification turn a planning range into a quote you can sign.

From our work

EM2 shows how scope multiplies effort. It is an enterprise platform for multi-day, multi-venue events with thousands of attendees and sessions. The back end runs as 8 .NET microservices on Azure, with separate services for schedule optimization, attendee matching and a Zoom integration, plus links to the Crimson and Positive ecosystems. Each integration is its own service with its own tests, which is exactly the kind of work that pushes a project into the upper rows of the table.

The SaaS ETL platform we built is a product with two audiences: business users who build data pipelines without code, and technical teams who want APIs and diagnostics. It connects SQL Server, Oracle and MySQL plus CSV, JSON and XML files, with scheduled runs and real-time monitoring. Serving both audiences well is a cost driver in itself, since the same feature needs a simple path and an advanced one.

At the other end, the AgTech project rescue is a reminder that existing code is a cost factor. A previous developer had delayed the client’s project for more than six months. One OSKI engineer rebuilt the codebase from scratch and delivered it in two months, on time and on budget. For large systems, we also handle infrastructure moves such as Ben-Gurion University’s roughly 80,000-page site, which we migrated from Azure to AWS without downtime.

Where OSKI fits

OSKI Solutions builds custom software and web applications on .NET, React, Angular and Vue, with engineers mostly in Ukraine and an EU-registered company in Estonia. We work fixed price for defined scopes and with dedicated teams for longer roadmaps, and we take over and run existing systems through maintenance and support. If you have a scope, or just a list of workflows, we can turn it into a written estimate with hours per module.