Answers

What decides how much custom software costs, and why do projects run over?

Ascent Vision · Published October 28, 2026

The cost of custom software mostly follows how much it has to do and how many other things it must work with: the tasks it handles, the kinds of people who use it, the tools it connects to, the data that must move in, and the testing and upkeep. Projects often run over because the scope grows, decisions come late, or feedback arrives after the work is done. A smaller first version and a written change list help.

What makes a software job bigger

Each of these can push the cost up or down. This answer gives no figures, because they depend on the job, and a useful quote shows which of these it assumes.

• How much it does. Each task, screen or report adds work, and the awkward cases often add more than the usual ones.
• Kinds of user. Staff, customers and managers often need different views and different sign-in rules.
• Connections to other tools. Each tool it must talk to, such as payments, calendar, email or accounting, is more to build and to check, and the other tool's rules can change.
• Data to bring in. Moving records from spreadsheets or an old system takes longer when they are messy or incomplete.
• Design. A plain working layout is usually a smaller job than a polished one that must look right on every screen.
• Testing. Software that handles bookings, money or private details usually needs more checking.
• Hosting and upkeep. Updates, renewals and fixes carry on after launch, as the related answer on keeping custom software running lists.
• Changes after launch. Once people use it, they often see what they want changed.

Why projects run over

Scope creep means the work growing past what was agreed. It rarely arrives as one big request. It is usually many small ones, each sounding easy.

• Ideas are added along the way without anyone saying what each adds.
• Decisions are unclear or late, so work waits or is redone.
• Feedback comes at the end, when a misunderstanding is expensive to undo.
• Surprises turn up, such as data that is messier than expected or a connected tool that works differently from its description.
• The brief listed features instead of the job the software must do.

Habits that keep it on track

• Ask for a first version that does the main job from start to finish, as the related answer on checking a developer's work describes, and learn from using it before adding extras.
• Keep one written change list. Each new idea gets a yes, no or later, and what it adds is agreed before work on it starts.
• Approve work in stages, as the related answer on checking a developer's work describes.
• Name one person on your side who decides, and give feedback at each stage in writing.

Reading a quote

A quote is only as firm as the scope behind it. Ask each provider the same questions, and use the same written brief; the related answer on what to have ready before hiring a software developer helps you write it.

• What is included, and what would count as new work?
• How are changes priced and agreed, before the work or after?
• Is the quote for a defined scope, or based on time spent? If time, how often will I see how much has been used, and can we set a point to review?
• What does it assume about my data and the tools it connects to?
• What running and upkeep does it leave out?

Related answers

• What should you have ready before hiring a software developer?
• How do you check a developer's work before paying for more?
• What does it take to keep custom software running after launch?