Commissioning Custom Software — From an Idea to a Working System

First, an agreement: this course is not about programming. You will write no code and

need no technical background. It is about the role you play in a software project — the role

that decides its outcome more than any technical choice does.

Who I am, and why that matters to you

I build these systems. That means I am the party you will be dealing with, which is a fair reason

to be sceptical of my advice.

So let me say it at the outset: much of what I will teach you here **makes me harder to deal

with** — you will write a scope that stops me expanding it, ask for acceptance criteria I will be

measured against, and hold a final payment until you are satisfied. That is deliberate. I would

rather have a client who knows what they want than one who signs quickly and argues two months

later.

Where projects actually fail

Failure is rarely technical. Usually it falls into one of four:

Vague scope. "We want a system to manage sales" is a sentence everyone understands

differently. Both parties sign while imagining two different things, and find out at delivery.

The request changes mid-build. Change itself is not the problem — the problem is treating it

as free. Every change has a time cost and a money cost, and when neither is counted the project

slips and both sides get tense.

No decision owner. The developer asks a question and finds nobody to answer, or finds three

people answering three ways. Every waiting day is a lost day.

"Done" with two meanings. The developer means "I wrote the feature," the client means "it

works here the way I pictured it."

Notice that three of those four sit in your court. That is the good news: what sits in your

court you can fix.

What your role really is

Not understanding the technology. Your role is four things:

1. Describe what must happen in your business, precisely enough that it cannot be read two

ways.

2. Decide when asked, and quickly.
3. Test what is delivered, yourself or with whoever will use it.
4. Protect yourself in the contract, on what you own and what you can leave with.

Every lesson after this one addresses one of those.

The assumption that costs the most

"The developer is the expert, they know what I need better than I do."

They know how it gets built; you know what must get built. Nobody in the world knows your

business the way you do. When you hand the decision to someone who does not know the details of

your day, you get a system that is logical and elegant and does not resemble your business.

Three questions before you build at all

Before finishing the course, ask yourself three questions that may end it early — which is a saving,

not a loss:

1. Is there an existing tool that solves 80% of my problem? A great deal of what gets

commissioned already exists and is bought on a modest monthly subscription. Building what is already

built is an expensive decision that needs a reason. The acceptable reason: the remaining 20% is

genuinely your competitive advantage, not merely a difference of habit.

2. Is my problem information, or procedure? If orders get lost because nobody owns following

them up, a system will document their loss precisely. Procedure is fixed by a management decision,

not by programming — and programming afterwards is far more useful.

3. Are my operations stable? If you change how you work every couple of months, you will build a

system in a shape you abandon before it is finished. Postponing six months is a legitimate decision.

A "no" on the second or third means: stop the project now. I would rather tell you that here than

have us discover it together three months in.

What you leave this course with

A document. A requirements brief written in your own hand, fit to send to any developer — me or

anyone else. The eight lessons build it piece by piece, and the last one assembles it.

Before you continue

Write in one line: what problem are you trying to solve with this system? Not the solution — the

problem. We will come back to that line more than once.