Describing your need in one sentence

Most people believe you need a thick document to start custom software: a long feature list, a priority matrix, a technical vocabulary they don't have. So they put it off, and the friction stays, every morning, at the same hour.

You need far less. To begin, you need a sentence. One clear sentence about a specific moment in your week that keeps snagging. klair starts from that sentence, asks you simple questions, and drafts the brief for you. Your job isn't to write the specification. Your job is to tell the truth about a friction, in a sentence anyone could understand.

Here is how to write it, in six short steps. Bring a coffee, six minutes, and the problem you've been carrying for three weeks.

Pick one friction, just one

Don't start from the whole department. Start from the task that annoys you most this week, the one that comes back every day or close to it. A repeated moment, not a grand transformation project.

If several frictions crowd in, write each on its own line, then keep the first that came to mind, the one that surfaced without effort. It is almost always the right one, because it is the one you actually live, not the one you think you should cite.

Too broad. "Our back office is chaos."

Sharp enough. "Every morning, someone rekeys the orders that arrive by email into our stock software, by hand."

Name who feels it, and when

A friction always has a face and a time slot. Say who lives it, naming a role and not a person, and when it lands in the week. That is what turns a general complaint into a situation you can observe, measure, and one day fix.

The "when" matters as much as the "who". A task that returns every day does not carry the same weight as a quarterly chore, and the workshop needs to know that to aim well.

Vague. "We waste time on scheduling."

Placed. "On Thursdays, our branch manager spends two hours copying team availability into a shared spreadsheet."

Describe what happens today, not the fix

This is the step where nearly everyone slips. The temptation is to jump straight to the tool: "I'd need an app that...". Resist. Describe the current process as it truly unfolds, with its copy-pastes, its chasers, and its back-and-forth by email. Finding the solution is the workshop's job, not yours.

A simple test: if your sentence contains the word "app", "platform", or the name of a piece of software, you are already describing an answer. Step back toward the problem, and leave the solution open.

A disguised solution. "We need a client portal."

The problem described. "Our clients call to learn the status of their file, and on every call an account handler opens three different screens to answer them."

Add the outcome you want

A good friction sentence ends on what would be better. Not a feature: a human result. Time given back, an error avoided, an evening freed, a team that absorbs more without drowning. That is what tells the workshop when the work has succeeded.

Frame that outcome as a change of role rather than a gadget. Often the right target isn't to remove a person from the loop, but to move them from data entry to checking.

No target. "Invoicing takes us forever."

With a target. "At month end, our accountant reassembles hours from three files by hand before invoicing, and I'd like her to check a total that's already prepared rather than rekey everything."

Condense it into a single sentence

You now hold four pieces: who, when, what happens, and what you want. Assemble them in that order, with no clever phrasing. The shape almost always holds like this: "[When], [who] [does this painful thing], and I'd like [the outcome]."

For a medical practice, that gives a single line:

The sentence. "Every evening, our secretary retypes the reports dictated by the doctors into the practice template before sending them, and I'd like her to proofread a layout that's already done instead of typing it all."

One sentence. A reader who knows nothing about your trade understands it. Software can be born from that.

Reread, cut the jargon, drop the sentence in

A final pass. Remove the acronyms, the software names, the words only your trade uses. If a friend outside the sector doesn't grasp the sentence on first read, simplify further. Plain language isn't a courtesy: it is what lets the workshop, and you, sign off later without the slightest misunderstanding.

In HR, the same sentence gains a lot by losing its acronyms:

With jargon. "We need to automate onboarding and harden the HRIS."

In plain words. "When an employee arrives, our payroll officer rekeys the same information into four different tools, and I'd like her to enter it only once."

When the sentence stands on its own, it is ready. There is nothing left for you to write. You drop it in, and the questions come to you, one by one, in language you understand.

That is exactly what the klair workshop does. You enter your sentence, it takes it up, answers you, and the brief writes itself as the exchange unfolds. The full specification, the one you'll read and sign, is built from that first line.

Have a friction in mind? Write its sentence, then drop it in.

Let's map your frictions [blocked]