Software, or a process fix: the five questions we ask before we build.

Start with the job

Software pays for itself when it has a job to do: something people are doing badly, slowly, or not at all. Most requests for software do not start there. They start with a tool someone saw, or a competitor that has an app.

So before we agree to build anything, we ask five questions. They take an hour, and they save more money than most code does.

The five questions

• What should move? Name the number: hours, errors, days to invoice, inquiries answered.
• Who does this job today, and how? Watch it done once before designing anything.
• Would changing the process do it? If two teams stopped retyping the same order, is there still a problem?
• Does something you already own do it? Most ERPs and CRMs are used at a fraction of what they can do.
• Who will own it once it is built? Software without an owner is abandoned within a year.

What the answers tell you

If nobody can name the number, stop. If a process fix does the job, do that; it costs nothing. If a tool you already pay for can do it, configure it. Only when all three fail is custom software the right answer, and by then you know exactly what it has to do.

The best software projects are the small ones that survived all five questions.

And AI

The same test, with one more question: what happens when it is wrong? An assistant that drafts a reply for a person to read is useful on its first day. One that sends the reply itself has to earn that. Put AI where a mistake is cheap and a person is watching, and move the line as it proves itself.

When the answer is yes

Then build the smallest thing that moves the number, in your own accounts, with tests from the first week. Measure it against the number you named. If it does not move, say so and stop.