How much does custom software cost?

Send the same idea to three suppliers and you may get back three wildly different numbers. That rarely means anyone is trying to cheat you. Each of them hit gaps in your brief and filled those gaps with their own guesses. If you want a software development cost you can rely on, your job is to take away as many of those guesses as you can before anyone opens a spreadsheet.

We wrote this for founders, operations leads and IT managers who need a realistic software project estimate before they commit a budget.

What are you actually paying for?

You're mostly paying for time. Add up the days of design, engineering, testing and project management your project needs, multiply by the rate of the people doing them, and you're close to the price. So anything that adds work pushes the cost up, and so does anything that makes the amount of work harder to predict. The days usually fall into five buckets.

Engineering covers the front end (what people see and click), the back end (the server, business rules and database) and any APIs, the connectors that let systems exchange data. Infrastructure means hosting on AWS or Azure, backups, monitoring and a CI/CD pipeline (an automated process that tests and releases each change). Hosting, paid licences and ongoing support are often priced on their own, so ask for them in writing.

How much does custom software cost to build? The real drivers

Most of the price comes down to a few factors. If you can describe each of them clearly, any competent team will size your project with far more confidence.

How much each driver usually moves the price

• Integrations with other systemsHigh
• Compliance and securityHigh
• Number of platformsHigh
• User roles and permissionsMedium
• Data migrationMedium
• How settled the scope isMedium
• Reports, alerts and admin toolsLow

This is our usual view. On your project, any one of these could matter more.

Integrations with other systems

An integration connects your software to another system through its API: a payment provider such as Stripe, accounting software such as Xero, a customer database such as Salesforce, or your own older internal system. Treat each one as a small project of its own. A modern API with good documentation might take a few days to connect. An old system with no API at all can take weeks.

Compliance and security requirements

Card payments, health records and personal data bring rules such as PCI DSS (the card payment security standard), GDPR (the European data protection law) and HIPAA (United States rules for health data). To meet them you'll need encryption at rest and in transit, audit logs, tighter access controls and penetration testing, where specialists try to break in before real attackers get the chance. Build this in from the first week. Bolting it on after launch costs far more.

Number of platforms

A web application is one product. Add iOS and Android apps and you now have three to build, test and release. React Native or Flutter let one codebase run on both kinds of phone, but each platform still needs its own testing and its own app store review. Decide early which platforms you really need at launch.

How user roles and data shape the scope

Every user role, whether that's a customer, a staff member, a manager or an administrator, adds screens, rules and tests, because the team has to prove each person sees only what they should. Moving data out of an old system means matching up fields, cleaning out duplicates and checking the results, so tell suppliers how many records you have and how messy they are. If you already know which screens you want, the build is shorter. If all you have is a rough idea, expect extra discovery time and more review rounds. And don't forget the small stuff: alerts, exported reports and admin areas all take time, so list the ones you need at launch.

A total on its own tells you very little. Always ask what it includes and what the supplier assumed to get there.

Fixed price or time and materials?

Once the work has been sized, you'll usually be offered one of two ways to pay. Both are fair, but they leave the risk with different people, so pick the one that matches how settled your plans are.

Fixed price and time and materials compared

Fixed price

One agreed price for an agreed scope, paid in milestones. Works best when you know what you want.

• Budget certaintyHigh
• Freedom to changeLow
• Your overrun riskLow

Time and materials

You pay for the days actually worked, at agreed rates. Works best when your plans will change.

• Budget certaintyLow
• Freedom to changeHigh
• Your overrun riskHigh

Fixed price suits a product you can describe well, with a clear finish line. Expect the supplier to spend real time on discovery first and hand you a written scope that says what's in and what isn't. You can still change your mind later, but each change gets its own estimate and your approval before anyone starts on it.

Time and materials suits an early product that you plan to shape as real users give feedback. The catch is that you have to keep a close eye on progress and spending. Most teams handle this with sprints (short working cycles, often two weeks) and a regular report of the hours used.

At V6 Cube we cover both situations with a fixed project or a dedicated team. On a fixed project, we agree a fixed estimate with you before any work begins. A dedicated team works at an agreed rate for as long as you need it.

How is a software project estimate built?

Whoever you hire, a careful estimate goes through roughly the same steps. Once you know them, it's much easier to tell whether the number in front of you was thought through or pulled from the air.

From idea to a number you can trust

1. Split the workTasks of a few days each.
2. Size each taskAgainst similar past work.
3. Name unknownsWhere the doubt sits.
4. Add a marginShown as its own line.
5. Key stepWrite the scopeWhat is in and out.

A good estimate points to where the doubt sits, for example an integration nobody has tried yet, and may suggest a short technical trial to settle it before you commit. Look for the margin for surprises as its own line; if it's spread quietly across every task, you can't see how big it is. Then check the written scope, because a price only means something when you can see exactly what it pays for.

Which budget band fits your project?

We don't publish prices, because two projects that sound alike can end up far apart once you count the drivers above. Our project enquiry form lets you choose a broad band: under 5,000 USD, 5,000 to 15,000 USD, 15,000 to 40,000 USD, or over 40,000 USD. Our project estimator suggests a band from three quick answers. A band lets a team suggest a sensible first version that fits your money. If the budget can't move, say so plainly, and a good team will tell you what they can build well inside it.

A brief template for an accurate estimate

When a brief is vague, the supplier has to guess, and guesses get padded. You don't need a full specification to fix that. Copy the headings below and write a few honest lines under each one.

1. The problem. What goes wrong today, who it affects and what it costs you.
2. The goal. One measurable outcome, such as fewer support calls.
3. Users and roles. Each type of user, roughly how many, and their main tasks.
4. Key features. A short list, marked as needed at launch or can wait.
5. Platforms. Web, iOS, Android, or a combination.
6. Integrations. Every system it must connect to, and whether each has an API.
7. Data. What must move across, from where, and roughly how much.
8. Rules and security. Any regulation or hosting requirement, such as data staying in one country.
9. Timing and budget. Any fixed launch date, and a budget band.
10. Examples. Screenshots, products you admire, or a rough sketch.

Warning signs in a software quote

• A total with no written scope. Later on, you'll have no way to tell whether something was left out.
• A price before any real conversation. If a number lands in your inbox within minutes, it's a guess.
• Unclear ownership. Once you've paid, all the code and designs should belong to you.
• No process for changes. Ask how new requests get priced and who approves them.
• No milestones. A larger project should come in stages you can test and pay for one at a time.
• No mention of testing or hosting. You'll pay for both eventually, so find out now.

What to do next

Write your brief, pick a budget band and send the same pack to two or three suppliers, so you're comparing like with like. Ask each of them to list the assumptions behind their number. In our experience, the suppliers who explain their thinking are the ones you can trust.

If you'd like to see how a clear scope turns into results, read how we rebuilt a loan origination platform that approves applications 63% faster. When you are ready, our custom software development team can turn your brief into a fixed estimate. We reply within one business day, and projects usually start within one to two weeks. Working to a grant or a budget your board has approved? See how we plan nonprofit software projects.