Software company in Newcastle, NSW: built for the way you work.

It is a tool built around how one business already works, rather than a business changing how it works to fit a product. It is the same difference as a made to measure suit.

Off the shelf software is built for the average of thousands of businesses. Custom software is built for one, which is its advantage and its entire cost.

What people actually have built

• Internal tools that run the work.

  Jobs, scheduling, quoting, stock. The things a business currently tracks in a spreadsheet nobody else can read.

• Portals a customer can log into.

  Where somebody sees their own job, their documents or their progress without having to ring anybody.

• Connections between existing tools.

  Making what you already pay for talk to itself. That is automation, meaning a job that runs without anybody remembering, and it is often the whole job.

• Something genuinely new to sell.

  A product the business intends to put on the market. That is a different project with a different risk in it.

Anything built to hold customer details has to sit inside the Australian Privacy Principles.

When the way you work is genuinely different from everybody else, and that difference is why customers use you. Where the gap is only habit, a product will do it more cheaply.

This is the question worth being honest about, because a build is the most expensive answer available and it is very often the second best one.

Signs it is worth building

• Everything depends on one spreadsheet.

  A file the business cannot run without, that one person understands, and that stops the work when they are away.

• Nothing on the market actually fits.

  Somebody has genuinely looked, and the products either do a fraction of it or demand the business works differently.

• What changes is the business itself.

  How you schedule, price or deliver is why customers choose you. Bending that to fit a product costs you the reason they came.

• Somebody types the same data in twice.

  Into two systems, by hand, every day. That is a connection job, and it is the cheapest build there is.

The signs it is not worth building are just as clear. Nobody has looked at what exists, the process has never been written down, or the current product is irritating rather than actually wrong.

Nearly always, where something exists that does eighty per cent of it. A product has years of other people's problems already solved inside it, which usually covers more ground than the last twenty per cent would.

A product you buy has been used by thousands of businesses. The edge cases you have not thought of have already happened to somebody else and been fixed.

Custom software starts with none of that. Everything it has to handle has to be thought of first, and the ones nobody thought of turn up later as faults.

The honest sequence is to look at what exists, then at what the business already pays for, and only build the part with genuinely no answer. On most projects that part is much smaller than the original idea.

The middle option gets forgotten. Connecting two products you already own, so they stop needing a person in between, is a small build carrying most of the benefit.

The code, the data, and the accounts it runs in. Software you cannot take to another developer is rented, whatever the invoice happened to call it.

This matters more here than anywhere else on the site, because software keeps needing work and whoever holds it holds the relationship.

What comes back at the end

• The code itself.

  In an account in the business's name, with a copy that can be handed to another developer without asking anybody's permission.

• All of the data.

  Exportable, in a readable format, at any time. The customers and the jobs are the genuinely valuable part of it.

• Every account it depends on.

  Hosting, and anything the software runs on, in the business's own name from the start.

• Enough written down to hand over.

  How it is built and how it goes live. Not a manual, just a page another developer can start from.

All of that is set up on the first day here, because retrofitting it is awkward and asking for it afterwards is a conversation nobody enjoys.

Write the process down, check what already exists on the market, and build the smallest useful version of it. Put that in front of real work early, and add only what the real work asks for.

Projects that go badly are nearly always the ones that tried to ship everything at once.

1. Write the process down

As it actually happens, with the people who do it. Where three people do it three ways, that is the first finding, and it is a business decision rather than a software one.

2. Check what already exists

Properly, including the features of tools the business already pays for. This step regularly ends the project, which is a good outcome rather than a wasted one.

3. Build the smallest useful version

The part carrying the most weight, on its own. Not the whole idea, and not a prototype nobody can actually use for anything.

4. It goes in front of real work

With real jobs and real people, as early as possible. Everything that comes out of it changes what to build next.

5. Add only what the real work asked for

Not the list from the first meeting. Half of that list turns out to be unnecessary once the first version is being used daily.

6. Plan for the upkeep

Software is never finished. Whoever holds it has to be reachable, and that is an ongoing arrangement rather than a project cost.

Longer than a website and shorter than the first estimate, where the smallest useful version goes first. Projects that go badly are nearly always the ones that tried to ship everything at once.

The order it happens in

• First the process goes down on paper.

  With the people doing it. Nobody builds anything at this stage, and this is where a project is saved or lost.

• Then the smallest useful version is built.

  One piece, working, put in front of real work as early as it can possibly go.

• Then it grows on what the real work asked for.

  Which is a considerably shorter list than the one from the first meeting, every single time.

The projects that fail are not usually the technically hard ones. They are the ones where nobody wrote the process down and everybody agreed to build everything.

Ask whether you should build this at all, who holds the code, what a change costs afterwards, and what happens if the developer stops working. The first answer tells you the most.

These are worth asking of any developer, including this one, so the answers given here are underneath each question.

• Should I build this at all?

  A developer with nothing off the shelf to suggest has not looked properly. If the answer is to buy something, that gets said.

• Who holds the code and the data?

  The business does, in its own accounts, from the very first day and before any code is written.

• What does a change cost afterwards?

  A rate and a rough time. Software keeps needing changes, so this is the real long term number.

• What happens if you stop working?

  Another developer picks it up from the code and a page of documentation. That is what makes the answer an honest one.

A business whose process has never been written down is not ready for this conversation. Writing it down is the useful next step whether or not anybody ever builds anything.