The most important skill is not technical: how to describe what you want

There is no secret phrasing

You do not need to learn prompt engineering to build business software this way. The description that works is plain professional language, aimed at a competent newcomer who does not know your company.

This is worth saying clearly because a whole industry of advice suggests otherwise. Magic words do not exist. What exists is a set of questions your description either answers or leaves open, and the ones left open get answered by something that has never met your business.

The test is simple and you can apply it before you type anything: if you handed these paragraphs to a capable person who started on Monday, could they do the job by Friday without asking you twelve questions? If not, the missing twelve answers are what to add.

Start with the nouns, not the screens

List the things your business keeps records of, before you describe any button. Clients, orders, vehicles, courses, policies, shifts. The records are the part that is expensive to change later; screens are cheap.

Most people begin by describing a screen, because a screen is what they can picture. It works for the first session and then quietly causes trouble, because two screens that both show "the client" can hide the fact that nobody decided whether a client and a contact are the same thing.

Do it in this order and the whole exercise gets shorter: name each record, say what belongs to what, then describe the screens as views onto those records. Ten nouns is a normal small system. Thirty means the description covers two systems and should probably be split.

The six things that carry the weight

Who uses it and what each of them may see; what is stored about each record; the steps of the main job in order; what must never happen; what is sent to whom and when; and what you personally look at on Monday morning.

Write the rules that are invisible to everyone but you

Every business has a handful of rules that are obvious inside it and unguessable outside it. These are the highest-value sentences in the entire description.

A regular customer does not pay a deposit. A quote over five thousand euro goes to the owner first. Nothing gets invoiced before the photographs are attached. The Sofia branch numbers its jobs separately. None of these can be inferred from anything, and each of them is the reason a piece of software is either used or quietly abandoned.

Write them as short flat sentences, one rule per line, and put them under a heading of their own. They will be the part you come back to when you change the system later, and the part a colleague reads to understand how the business actually works.

Say what must never happen

Negative rules are the ones people forget and the ones that hurt. Double bookings, deleted records, a colleague seeing salaries, an invoice number reused, a date in the past accepted.

Prohibitions do not come out of a description of the happy path, because when you imagine the process working you are imagining people doing the right thing. What breaks a system in week two is somebody doing a reasonable thing in the wrong order.

Three or four negatives is usually enough, and they are quick to write once you know to look for them. The prompt that works: finish the sentence "the worst thing this system could let someone do is" three times.

Then describe changes the same way

The description is not a one-off document. After the first version exists, every change is one or two sentences of the same kind, and this is where most of the real design happens.

The first version is a guess by everyone involved, including you. The changes that follow the first week of real use are where the system becomes correct, and they are usually small: this field is not needed, this list should be sorted by date, this reminder should not go out on Sundays.

Keep the description as a living document rather than throwing it away after the build. Six months later, when somebody asks why the system does something odd, the answer is usually a sentence in there that everybody agreed to and then forgot.

The failure that no method fixes

Three people describe the same process three different ways, nobody notices, and the system faithfully implements one of the three. It then gets blamed for being wrong.

This is the single most common way these projects fail, and it is not a software problem at any point. The disagreement existed before, hidden by the fact that each person was doing their own version by hand. Writing it down is what exposes it, which is uncomfortable and is also the most useful thing writing it down does.

The practical defence is to have the description read aloud by someone who does the job, in front of someone else who does the job. Fifteen minutes. Anywhere they interrupt each other is a decision that has not been made, and it is far cheaper to make it now.

QUESTIONS