How much does custom software development cost?

Custom software costs whatever the effort to build it costs, multiplied by the rate of the team doing it, plus the costs of running and improving it afterwards. Effort is set by scope, complexity, integrations, the quality bar and how fast decisions get made, so two projects that sound alike can differ several times over. The honest answer is a range, built from a breakdown of the work, that narrows as the project becomes better defined.

This guide does not quote prices, because rates vary widely by country, seniority and model, and any single figure would mislead you. Instead it explains what drives effort, how professionals build estimates, and works through three realistic examples in hours, weeks and team shape that you can adapt to your own project. For a quick first range on your own idea, try our software cost calculator.

Why there is no honest single number

Early in a project, almost everything that determines cost is still unknown: the exact features, the edge cases, the state of the systems you must integrate with, the decisions you have not made yet. Steve McConnell’s white paper on the cone of uncertainty describes how estimates made at the initial concept stage can be out by a factor of four in either direction, a sixteen-fold range from lowest to highest, even when skilled estimators make them. The range narrows only as decisions are made: defining the product, detailing requirements, designing the interface. McConnell notes that much of that narrowing happens in the first 20–30% of a project’s calendar time.

Two consequences matter for buyers. First, a precise quote for a vague idea is not more accurate than a range; it just hides the risk, usually in padding or in future change requests. Second, the way to get a reliable number is to reduce the uncertainty, typically through a short discovery phase, not to ask for more time on the estimate. As the same paper puts it, the cone is the best case: a poorly run project does not narrow at all.

What you are actually paying for

A software budget has more parts than the build. Separate them before comparing any quotes:

The main cost drivers

Effort grows with the following factors. Most are visible early if you know to look for them.

Scope: users, roles and workflows

Count the types of user (customers, staff, managers, partners, administrators), the distinct workflows each performs, and the screens or API endpoints those workflows need. Each additional role adds permissions logic, screens and test cases. Scope is the single biggest lever you control.

Complexity of the business rules

A form that saves data is simple. Pricing rules with dozens of exceptions, scheduling with constraints, approval chains, financial calculations that must reconcile to the cent, or anything regulated, is not. Complexity often hides in sentences like ‘it just needs to work out the price’.

Integrations and data migration

Every connected system (accounting, CRM, ERP, payments, identity provider, a partner’s API) brings its own data model, limits, quirks and testing needs. Old or poorly documented systems cost far more to integrate than modern ones with good APIs. Moving data from spreadsheets or a legacy database is its own small project: cleaning, mapping, rehearsing and verifying it.

Platforms

A web app alone is one thing. Adding iOS and Android apps adds mobile engineering, device testing, store submission and yearly platform updates. Cross-platform frameworks reduce but do not remove that extra work, and almost every app still needs a backend and an admin interface.

The quality bar

Non-functional requirements are where quotes differ most quietly: security level, availability targets, performance under load, accessibility to WCAG 2.2, audit trails, data residency, multiple languages or right-to-left layouts. Each is legitimate, each costs effort, and a quote that does not mention them has probably not included them.

Design depth

An internal tool built from a well-made component library needs far less design than a consumer app where the experience is the product. Brand-level visual design, motion and extensive user testing are worth it when they drive revenue, and an unnecessary expense when they do not.

AI features

Calling a language model is cheap to build. Making its output reliably good is not: you need a set of test cases with known good answers, a way to run them on every change, guardrails for bad output, cost and latency controls, and monitoring in production. Budget for evaluation as a first-class piece of work, not an afterthought.

Decision speed on your side

The fastest teams in the world slow down when they wait a week for answers, or when every decision needs a committee. A single product owner with the authority and time to decide is one of the cheapest ways to reduce cost.

How professional estimates are built

There are several established techniques. Good estimators use more than one and compare the answers; when two methods disagree badly, that is a sign something is not understood yet.

Whatever the method, a credible estimate states its assumptions (what is included, what is not, what the client provides), its biggest risks, and the range it is confident in. Ask for all three.

Team shape matters more than headcount

Duration is not effort divided by any number of people you like. Fred Brooks observed decades ago in The Mythical Man-Month that adding people to a late project makes it later, because new people need onboarding and every extra person adds communication overhead. Small, senior teams waste less effort on coordination and rework, which is why the examples below use two to four people rather than ten.

A typical small product team includes a senior lead engineer who owns architecture and quality, one or two engineers (full-stack, backend or mobile as needed), a product designer who is busiest at the start, and testing capacity that may be a dedicated QA engineer or shared across the team. Someone must also run the project and keep stakeholders aligned; in small teams this is often the lead engineer working with your product owner.

Worked example 1: an internal operations tool

The brief: a web application to replace a set of spreadsheets used to manage jobs from request to invoice. Three user roles (requester, coordinator, manager), around fifteen screens, single sign-on with the company’s identity provider, integrations with the accounting system and email, reporting with exports, and a one-off import of existing spreadsheet data. Desktop browsers only, English only, no public access.

Team shape: a senior lead engineer and one full-stack engineer full time, a designer part time in the first weeks, and part-time testing: roughly two and a half people on average. Assuming around 32 productive hours per person per week (after meetings, reviews and admin), that is about 80 hours a week, so roughly 10 to 16 weeks to first release. The accounting integration is the widest range in the table: if its API is modern and well documented, expect the low end; if it is an older system with partial documentation, the high end.

Worked example 2: a customer booking app with a web admin

The brief: iOS and Android apps for customers to find, book and pay for appointments, with push, email and SMS notifications. A web admin for staff to manage availability, bookings and refunds. Card payments through a payment provider. Two languages, one of them right-to-left. Accessibility to WCAG 2.2 AA. Built cross-platform to share one mobile codebase.

Team shape: a senior lead engineer, a mobile engineer and a backend engineer, a designer who is heavily involved for the first third and lighter afterwards, and part-time QA: close to four people on average, or about 120 productive hours a week. That gives roughly 13 to 20 weeks to a first release in both stores. Building two native apps instead of one cross-platform app would add most of the mobile line again, and is worth it only when the app depends heavily on device capabilities.

Worked example 3: a B2B SaaS MVP with one AI feature

The brief: a web-based SaaS product where business customers sign up, invite colleagues, upload documents and work through a review workflow. One AI feature summarises each document and flags clauses for review, using a hosted language model. Subscriptions with self-service billing. Audit logs, because customers will ask. One language, web only.

Team shape: a senior lead engineer who also owns the AI work, a full-stack engineer, a designer part time and shared testing: about three people, or 96 productive hours a week. That is roughly 13 to 20 weeks to a launchable MVP. Notice that the AI feature is a fifth or less of the total; the bigger cost is everything a SaaS product needs around it. Our SaaS development guide covers those foundations.

How to read these examples

• They are illustrations, not quotes. Real projects differ in ways a short brief cannot capture.
• The low column assumes clear decisions, cooperative third-party systems and no surprises. The high column assumes a normal number of surprises. Neither includes a major change of direction.
• AI-assisted development can shorten some build lines, especially boilerplate, tests and repetitive screens. It does not shorten discovery, decisions, integration with difficult systems or review.
• To turn hours into money, multiply by the blended rate of the team you are considering. To turn them into calendar time, divide by the team’s productive hours per week, and remember that a bigger team does not divide time evenly.

A good estimate is not a promise about the future. It is a clear statement of what is known, what is assumed and where the risk sits, so that both sides can manage it.

The costs after launch

The build is often the smaller part of what software costs over its life. After launch you will pay for:

• Hosting and infrastructure: usually modest for business applications, growing with traffic and data.
• Third-party services: email and SMS delivery, maps, payment fees, monitoring, error tracking, AI model usage. AI usage in particular scales with how much people use the feature, so set limits.
• Maintenance: security patches, dependency and framework upgrades, browser and operating system changes. Mobile apps have hard deadlines here: Google Play, for example, requires apps to target a recent Android API level or they stop being available to new users on newer devices.
• Support: answering questions, fixing defects, handling incidents within agreed response times.
• Evolution: the features the business needs next. Healthy software keeps a steady improvement budget.

Our software maintenance and support guide explains how to size and structure this ongoing work.

Pricing models and how they move risk

The same effort can be bought in different ways. Fixed price puts delivery risk on the supplier, who will price that risk in and protect scope tightly; it suits small, well-defined pieces of work such as a discovery phase or a clearly specified first release. Time and materials keeps flexibility and puts budget risk on you, so it needs strong prioritisation and transparent reporting. Monthly sprints with a fixed team give a predictable spend with priorities reset each cycle, which suits ongoing product work. Our comparison of fixed price vs time and materials covers when each is the better deal.

How to reduce the cost without reducing quality

1. Shrink the first release. Ship the smallest version that delivers real value to real users, then let usage decide what comes next. See how to scope an MVP without wasting budget.
2. Buy commodity parts. Authentication, payments, email, search and file storage are solved problems. Build only what differentiates you.
3. Start on one platform. A responsive web app or one cross-platform app may be enough for the first release.
4. Run a short discovery. It costs a little up front and narrows the estimate range more than anything else.
5. Name one decision-maker. Fast answers save more time than any tool.
6. Keep the team small and senior. Fewer people with more experience usually means less rework and less coordination.
7. Do not cut testing or security. Those cuts are paid back later, with interest, in incidents and rework.

Red flags in a software quote

• A precise figure for a vague brief, with no assumptions or exclusions listed.
• No line for testing, launch, project leadership or data migration.
• No mention of security, accessibility or performance requirements.
• A team list that does not say who is senior, or who will actually do the work.
• A price far below every other quote, with no explanation of why.
• Nothing about what happens after launch, or about who owns the code and accounts.

Our guide on how to choose a software development company has more on comparing proposals fairly.

How Authect estimates

At Authect, the founders who will build your project do the estimate, not a salesperson. We break the work down, state our assumptions and exclusions, and give you a range we are prepared to stand behind, then narrow it through discovery. Every project is led by a senior engineer, teams are small, and we use AI to accelerate delivery with an engineer reviewing every line.

We work as fixed-price projects, monthly sprints, or support and evolution, and you own the code, infrastructure and designs from day one. For a first range on your own idea, use the software cost calculator; for an estimate based on a real conversation, get in touch.