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

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.

Most businesses run on a stack of products that each do part of the job, with a spreadsheet bridging the gaps. That works, and it keeps working until the spreadsheet is the business.

What gets built

• Internal tools. Jobs, scheduling, quoting, stock. The things a business currently tracks in a spreadsheet nobody else can read.
• Client portals. Where a customer sees their own job, their documents or their progress without ringing you.
• Connections. Making the tools you already pay for talk to each other. This is automation, which means a job that runs without anybody remembering, and it is often the whole job.
• Something genuinely new. A product the business plans to sell. 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. If the difference is just habit, a product will do it cheaper.

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

Signs it is worth building

• The spreadsheet is load bearing. A file everything depends on, that one person understands, and that breaks when they are away.
• Nothing on the market fits. You have actually looked, and the products either do a fraction of it or demand you work differently.
• The difference is the business. How you schedule, price or deliver is why customers choose you. Bending that to fit a product costs you the reason.
• The same data is typed in twice. Into two systems, by a person, every day. That is a connection job and it is the cheapest build there is.

Signs it is not: nobody has looked at what exists, the process it would encode has never been written down, or the reason is that the current product is irritating rather than wrong.

Nearly always, if something exists that does eighty per cent of it. A product has years of other people's problems already solved in it, and that is worth more than the last twenty per cent.

A product you buy has been used by thousands of businesses, which means 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, and the ones nobody thought of turn up later as faults.

The honest sequence is: look at what exists, look at what you already pay for, and only build the part that genuinely has no answer. On most of the projects we are asked about, 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 between them is a small build with 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 called it.

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

What comes back at the end

• The code. In an account in the business's name, with a copy you can hand to another developer without asking permission.
• The data. Exportable, in a readable format, whenever you want it. Your customers and your jobs are the valuable part.
• The accounts. Hosting, and anything the software depends on, in the business's name.
• Enough documentation to hand over. How it is built and how it is deployed. Not a manual, a page another developer can start from.

Ours is set up that way from the first day, because retrofitting it is awkward and asking for it later is a conversation nobody enjoys.

Write down the process, look at what already exists, build the smallest useful version, put it in front of real work, then add only what the real work asked for.

1. Write the process down

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

2. Look at what already exists

Properly, including the features of the tools you already pay for. This step regularly ends the project, which is a good outcome.

3. Build the smallest useful version

The part that carries the most weight, on its own. Not the whole idea, and not a prototype nobody can use.

4. Put it in front of real work

With real jobs and real people, early. Everything you learn here changes what gets built 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.

6. Plan for it needing upkeep

Software is not finished, it is in service. Whoever holds it needs to be reachable, and that is an ongoing arrangement rather than a project cost.

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

The order it happens in

• The process gets written down. With the people doing it. Nothing is built yet, and this is where a project is saved or lost.
• The smallest useful version gets built. One piece, working, in front of real work as early as possible.
• It grows on what the real work asked for. Which is a shorter list than the one from the first meeting, every 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 they think you should build this at all, who holds the code, what a change costs afterwards, and what happens if they stop working. The first answer tells you the most.

We do this work in Newcastle, so we are not neutral. These are the questions we would want asked of us.

• Should I build this at all? A developer with nothing off-the-shelf to suggest has not looked. We say when the honest answer is to buy something.
• Who holds the code and the data? The business, in its own accounts, from the first day. Ours is set up that way 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 honest.
• Am I locked in? Ours runs month to month and always has. Any arrangement you cannot leave at the end of a month is worth a second look.

A business whose process has never been written down is not ready for this conversation, and writing it down is the useful next step whether anything gets built or not.