How much does custom software cost? What actually drives the price

If you have ever asked a developer "how much does an app cost?" and got "it depends," you know how unsatisfying that is. It is also, annoyingly, true. But "it depends" is not an answer, so let's talk about what it depends on.

We are not going to put a number on this page. Any figure we printed would be wrong for most people reading it, and it would age badly. What we can do is show you where the money goes, so you can judge a quote on your own.

Scope beats hourly rate

People compare quotes by hourly rate. That is usually the wrong thing to compare. A cheaper rate on a vaguer plan often costs more in the end, because the extra hours get spent figuring out what was meant.

What really moves the price is how much the software has to do. Think in terms of:

• How many user types there are. An app for one kind of user is far simpler than one where customers, staff, and admins all see different things.
• How many integrations. Every outside system (payments, accounting, shipping, a CRM) is its own mini-project, with its own quirks and its own documentation of varying quality.
• How custom the logic is. A standard sign-up form is cheap. A pricing engine with eight exceptions is not.
• Where it runs. A web app, a mobile app, and a desktop app each have different build and testing needs. Doing all three is not three times the cost if the plan is sensible, but it is not free either.

The things that surprise people

A few line items that rarely make it onto the first napkin estimate:

Design. Not decoration. Working out how a screen should flow before anyone writes code is the cheapest place to fix a mistake. Skipping it tends to move the cost to the middle of the project, where it is more expensive.

Testing. Software that handles money or personal data needs to be tested properly. This is not optional work that you can trim.

Data migration. If you are moving from an old system, someone has to get the old data into the new one, and old data is almost always messier than anyone remembers.

After launch. Hosting, updates, fixes, and small changes continue. We wrote a separate piece on what software costs to keep running, because it catches a lot of first-time buyers off guard.

How to read a quote

When you get a proposal, look for these things before you look at the total:

1. Is the scope written out in plain language, or is it a vague paragraph?
2. Does it say what is not included? A good quote names its own limits.
3. Is it a fixed price, an estimate, or time and materials? Each is fine, but you should know which one you are signing.
4. What happens when you want a change halfway through? There should be a clear answer.

If two quotes are far apart, do not assume the cheaper one is a bargain or the pricier one is a rip-off. Ask each to walk you through what is included. The gap is almost always a difference in assumptions.

Ways to keep cost under control

You have more influence here than you might think.

• Start smaller than you want to. Build the one workflow that hurts most, ship it, and learn. Our post on what to build first goes into how to choose.
• Decide before building, not during. Changing your mind on paper is free. Changing it in code is not.
• Pick one decision maker. Projects slow down and swell when five people each have a veto.
• Be ready to cut. If a feature is "nice to have," put it on a list for version two. Most never come back, because by then you know better.

Is custom worth it?

That is the real question underneath the price one. Custom software is an investment, and it should pay itself back, through time saved, errors avoided, or revenue you could not have earned another way. If you cannot point to one of those, wait. If you can, the price starts to look different, because you are comparing it to what the problem already costs you every month.

Fixed price, time and materials, or retainer?

The way a project is billed affects who carries the risk and how flexible you can be. There are three common models, each with real strengths.

Fixed price. You agree a total for a defined scope. It gives you certainty about cost, which many people value, and works best when the requirements are clear and unlikely to change. The catch is that anything outside the written scope becomes a change request, and good vendors build a margin in for the risk they are taking. If your idea is still forming, a fixed price can feel restrictive.

Time and materials. You pay for the time spent. It is flexible, since you can adjust direction as you learn, and you only pay for what is actually done. The trade-off is that the final total is less certain, so it needs good visibility: regular reports on what has been done and a clear budget ceiling.

Retainer. You pay a set amount for a block of time each month. It suits ongoing development and support, where work arrives steadily and you want a team that knows your system.

Many projects mix these. A fixed-price discovery phase, followed by time and materials for the build, followed by a retainer for upkeep, is a common and sensible shape. Whichever you choose, the important thing is that both sides understand how change will be handled.

Where costs hide

Beyond the obvious items, a few things regularly catch people out:

• Third-party fees. Payment processing, email sending, maps, SMS, and similar services bill separately and scale with use.
• Licences and tools. Some components or design assets have licence costs.
• Content creation. Writing, photography, and translation can be a surprisingly large part of the budget if nobody has planned for them.
• Internal time. Your team will spend hours answering questions, testing, and providing feedback. That time has a real cost, even if it does not appear on an invoice.
• Training and rollout. Getting people to actually use the new system takes effort.
• Change. However well you plan, you will learn things along the way. Setting aside a contingency, often a modest percentage of the budget, is a sign of realism and not of poor planning.

Cheap and expensive mistakes

Some decisions look like savings and turn out to be expensive.

Skipping design and planning. It feels quicker to start building immediately. In practice, misunderstandings found during the build cost many times more than those caught on paper.

Choosing the lowest quote without scrutiny. If a price is far below the others, find out why. Sometimes the vendor is efficient; sometimes they have misunderstood the scope or plan to make up the difference through change requests.

Over-specifying. Asking for every feature up front inflates cost and delays learning. See what to build first.

Neglecting maintenance. A cheap build with no plan for upkeep can end up costing more over its life. We cover this in what software costs after launch.

Switching vendors midstream without handover. If a project changes hands, make sure documentation and code access are in order first, or you will pay twice for the same learning.

Think in terms of return

The right question is not "is this cheap?" but "what does it give back?" It helps to estimate the return in plain terms.

• Time saved. Hours per week multiplied by what those hours cost.
• Errors avoided. The cost of mistakes, rework, and refunds.
• Revenue enabled. New sales that were not possible before, or customers who stay because the experience is better.
• Risk reduced. The cost of what could go wrong if you do nothing, such as relying on a fragile system or a single person's knowledge.

If you can put even rough figures on two or three of these, you have a basis for judging whether a quote makes sense. A project that costs a lot but pays back clearly is a better decision than a cheap one with no clear benefit.

Start with a conversation, not a number

The most useful first step is rarely a price. It is a conversation about what you are trying to achieve, what is in the way, and what a sensible first version might be. A good team will help you shape a scope that fits your budget, rather than quoting a figure for a vague idea.

Come prepared with your problem, your constraints, and a rough sense of what matters most. With that, you can get a meaningful estimate, and a much clearer view of whether the project is worth doing. Our checklist on what to prepare before hiring a developer is a good place to begin.

How to compare two proposals fairly

When you hold two quotes side by side, line them up on the same basis. Put the features from each in one list and mark what each includes. Check the assumptions about design, testing, hosting, and support. Compare the timeline and how many people are working on it.

You will often find that the cheaper quote leaves things out, and the pricier one includes them. Add the missing pieces back with rough estimates and compare again. Only then can you say which is better value, and if you cannot tell, ask both teams to explain the gap.

We are happy to look at what you have in mind and tell you honestly what shape and size it is. Reach out and describe it in a few sentences. No pitch, just a straight read.