What Drives the Cost of Custom Software

You want to stop running orders through paper, spreadsheets and chat. You ask what an app would cost, and the answer comes back as a list of questions. That's frustrating when you're trying to decide whether the conversation is even worth having.

What sets custom software cost?

Custom software cost comes from the work it must handle, the rules behind that work and getting your team to use it. This article gives no prices on purpose: the price comes from the factors below, and any number before someone has looked at your business is a guess.

You deserve a straight answer. Getting one means turning "we need an app" into a job someone can understand, build and check. You can prepare much of that picture before paying anyone.

Eight things that drive custom software cost

Eight things drive the cost: workflows, process rules, connections, data, permissions, reports, decisions and rollout. Use it to explain what your business needs before comparing proposals. For each driver, separate what the first version must do from what can wait and what nobody has decided yet.

1. How many workflows and roles it covers

The more work the app takes responsibility for, the more there is to build and check. An order list is one job. Taking an order through stock checks, packing, delivery and returns is several connected jobs. Each person involved needs the right information at the right point.

At Silla, the app covers sales, warehouse work, delivery, complaints, purchasing and reports. That's a description of work, far more useful than saying "one app."

Pushes cost up: Bringing every department into the first version.

Keeps cost down: Starting with one complete flow, including the handoffs that make it useful.

2. How settled the process is

A settled process gives the software clear rules to follow. An unsettled process means decisions arrive after the build has started, and finished work needs changing. If sales and the warehouse disagree about when stock is reserved, that disagreement needs an answer before the app can handle it properly.

At Silla, stock is tracked by component, with reservations for open orders. A chair means a seat, a backrest and four legs. Those details shape what the app must know.

Pushes cost up: Building while the team is still arguing about how work should happen.

Keeps cost down: Agreeing on the normal path and the exceptions with the people doing the work.

3. Connections to other systems

Every connection adds another system whose behavior needs understanding and checking. Sending an order to a courier includes what happens when the address is rejected or the shipment stalls. A website, accounting tool or payment service adds its own rules, access requirements and ways for a transfer to fail.

Silla's app receives WooCommerce orders, creates courier shipments and checks addresses against the courier's address database. It also tracks shipments after collection. "Connect the courier" hides several separate jobs.

Pushes cost up: Several connections with unclear responsibilities for failed transfers.

Keeps cost down: Connecting only what the chosen workflow needs and checking access early.

4. Moving and cleaning old data

Moving data costs more when the old records need interpretation before anyone can trust them. Duplicate customers, missing product codes and conflicting stock counts need decisions, not just an import button. The useful question is which records the team needs to work on the first day in the new system.

Even the UK government's data quality framework treats a complete record and an accurate record as two different things. A spreadsheet with every cell filled can still be wrong.

Pushes cost up: Importing every old file without checking which copy is right.

Keeps cost down: Naming a person to resolve duplicates and checking the records before moving them.

5. Who can see and change what

Permissions add work because the system must enforce who can see, change and approve each kind of record. Hiding a button isn't enough. A warehouse employee packing an order and an owner approving an important change have different responsibilities, even when they use the same app and the same data.

Silla's warehouse has its own phone screen showing today's tasks. Important actions wait in an approval queue, and a system log records what happened.

Pushes cost up: Different exceptions for individual people without clear rules.

Keeps cost down: Defining permissions by responsibility, including approvals the business actually needs.

6. The questions your reports must answer

Reports cost more when nobody agrees on what the numbers mean or the underlying records don't contain the answer. A chart needs a definition before it needs a color. "Orders completed" could mean packed, collected by the courier or delivered. Those are different questions requiring different records and checks.

Silla's app shows warehouse output by day and employee without manual spreadsheets. The report has a clear subject, a time period and a person attached to the work.

Pushes cost up: Asking for every possible dashboard before naming a decision it supports.

Keeps cost down: Writing the business question and agreeing on the calculation first.

7. Decisions and changes during the build

Decisions affect cost when work waits for an answer or gets redone after conflicting answers. A new request can also change more than its own screen. Adding an approval step can affect permissions, notifications and reports. Someone needs authority to decide whether that addition belongs in the agreed build.

Before our work together, sales, operations and client relationships at DOMinvest all ran through Dean, its CEO. A build run that way waits on one person for every answer.

Pushes cost up: Several people giving different instructions and additions slipping into the build without review.

Keeps cost down: One authorized decision-maker, input from the team and a written decision about each proposed addition.

8. Rollout and training

Rollout takes work because your team has to run real jobs in a different way. People need to practice, see what happens when something goes wrong and know where the current record lives. The build needs to account for that work rather than stopping when the screens look finished.

At Silla, a packing task stays open until the correct model, color and quantity have been scanned. That rule changes the warehouse routine. It needs checking where packing actually happens.

Pushes cost up: Leaving the people doing the work out until launch.

Keeps cost down: Involving them early and including practice, checking and troubleshooting in the scope.

How to prepare before you ask for a proposal

Take one real order or job through these eight drivers with the people who handle it. Write down what happens, what fails and who decides. The goal is a clear first version that removes a painful piece of work, with enough detail to discuss what belongs in the proposal.

1. Pick the flow that hurts most. Choose something concrete, such as orders reaching the warehouse with missing details. Follow one real example from arrival to completion. Include a recent exception so the normal path doesn't hide the hard part.
2. Test what you can buy. Check whether a standard tool handles that flow. You can compare custom software with off-the-shelf tools before choosing what to build.
3. Prepare the records. Gather the files that hold current customers, products and open work. Agree on the master copy. Ask the person who knows the records to resolve missing codes and conflicting entries.
4. Name one person who can decide. Give that person authority to settle questions, with input from the people affected. A named contact without authority still has to take every question back to someone else.
5. Agree on a fixed scope. Write down the flow, connections, reports, permissions, data move and rollout work. Put later additions on a separate list. Keep necessary checks, access controls and exception handling in the first version.

Common mistakes when judging the cost

My view is that screen count and how simple an idea sounds get too much attention when owners judge cost. The rules behind the screens matter more. I would rather discuss one complete order, including a return, than count pages in a sketch that leaves the difficult decisions unanswered.

• Calling it "just a simple app." A short description can hide component stock, approval rules and courier failures. List the work behind the description.
• Comparing totals without comparing scope. Check whether both proposals include data preparation, connections, testing and rollout. A smaller job produces a smaller total.
• Treating faster coding as the whole saving. I build with AI coding tools to speed up writing code. My view is that most of the cost still sits in deciding what to build and getting people to use it.
• Cutting the parts that prevent mistakes. Silla's packing check requires the correct model, color and quantity. Removing a check like that would remove part of the reason to build the app.

Why a fixed price follows Discovery

A fixed price makes sense after Discovery because the job needs a defined scope before anyone can commit to it. You need agreement on the work, the data, the connections and what counts as finished. Otherwise, you and the builder can agree on a number while imagining different systems.

Carnegie Mellon's Software Engineering Institute explains that differing interpretations of requirements reduce estimate accuracy, especially early in software development. That's a reason to settle the important questions before committing to a build.

My paid Discovery takes 1-2 weeks and ends with a written proposal with a fixed scope and price. The paid Discovery article explains that stage. My work-with-us page sets out the engagement.

What to budget for after launch

Running costs continue after launch because the business keeps changing and the software needs attention. New products, changed responsibilities and different ways of working can create new work for the app. My ongoing support and improvements are monthly. Discuss those alongside the build so you understand the continuing commitment.

I stay involved through rollout, troubleshooting and improvements. Keep a list of changes that help the team do its work, then decide which deserve attention. A new report should still earn its place by answering a useful question.

Find the work that keeps coming back to you

If you're unsure which workflow deserves attention first, the Business MRI can help you see how much of the business runs on you. It's 10 questions, about 2 minutes, no email needed to see your result. You get a founder dependency score, your three weakest areas and a first move for each.