How We Work Out What Custom Software Should Cost (and How It Should Be Done)

The cost of custom software comes down to time. And the time a build needs is set by how well the problem is understood before anyone starts building. This is how we scope at Thesis OS, and how we think it should be done.

Start with the problem, not the feature list

We begin by looking at the problem itself. Who does it touch, how do they behave, what habits do they have, why do they have those habits, and what causes them? Once we understand that, we can describe the ideal behaviour and the habits that would get the business the outcome it wants.

That matters because software creates and establishes habits in the people who use it. If you want a goal achieved, the software has to make the right behaviour the easy one.

A recent example: Protée OS

Protée OS started with a multi-faceted problem. The business was receiving poor information from clients when they made an enquiry. It was either wrong or not there at all.

We didn't start by designing screens. We looked for patterns over a period of time, in how clients shared information and why they did what they did. Those patterns gave us an avatar of the person who would use the software.

From there we:

• —
  Identified the solution to the core problem.
• —
  Added solutions for both left-brain and right-brain users, because people build and share information in different ways.
• —
  Used the same data, once we had the core solution working, to solve more problems for every other stakeholder.

That last step is where the value compounds. The data collected to fix one problem should be working on others too.

What actually drives cost

Time is the biggest influence on price. Two things push it up:

• —
  The level of features. The more data sets involved, the larger the build.
• —
  How the data is treated. What the software has to do with the data is a major driver of cost.

If you want to understand a quote, ask how many data sets are involved and what has to happen to each one.

Where scoping goes wrong

We see some patterns from other developers that we think work against the business owner:

• —
  Walking into the first meeting with several people on the Zoom call, which can feel like an ambush rather than a conversation.
• —
  Scoping the work for longer than it needs to take, with sprints designed to generate the most revenue.
• —
  Building in stages, which stretches out the build and creates more work for the developer later.

None of that helps you get the outcome you wanted.

Questions to ask before you agree a scope

Before you sign off on a scope, ask:

1. 1.
   Does this solution solve the problem?
2. 2.
   Will it generate the outcome we want?
3. 3.
   Who owns the data?
4. 4.
   Who owns the code?
5. 5.
   Are there ongoing costs for maintenance?
6. 6.
   Will there be security updates?
7. 7.
   Will it update automatically?

If you can't get clear answers to all seven, the scope isn't ready.