Documenting software's business rules: extract them before it is too late

The value in your software is the years spent deciding how things work in your business. Those decisions live in two heads and code nobody rereads. Put them in French, and understand why the document outlives the code.

Documenting software's business rules takes days and saves years of decisions. On Reddit (r/vibecoding, July 2026), a regional maintenance company owner describes four years refining an internal tool's logic, with 95% of code AI-written, until a large group wanted to use it. They write that the value lies in the four years.

Where your rules live today

Inventory honestly. Some rules are in software as conditions written eight years ago by someone who left. Others are in two people's heads, the ones always asked 'what do we do when the customer is in a dispute?' A third group lives in a spreadsheet your accountant maintains alongside because the tool never had the field. None is readable by a newcomer, and none transfers with the code file.

A business rule in one French sentence

A business rule fits a sentence an employee understands: an order after Thursday noon ships the following week, a rejected quote stays readable for a year, an annual-contract customer pays no deposit. It has a trigger, consequence, and almost always an exception. The exception holds the value because it comes from a real problem encountered once that you never want again. Market software flattens those exceptions; we approached this through independent professions.

Extract them without stopping production

Three questions draw out material from people doing the work. When do you work around the software? What do you manually correct afterward? What changed when a customer became angry? Every answer provides a rule and exception in French without a developer present. Allow one hour per person and a notebook. The difficult questions method serves the same purpose with a stopwatch. An organisational consultant does this better than a machine when departments contradict each other: the machine transcribes what it hears; it does not arbitrate between sales and production.

A rule does not emerge in a plenary meeting. It emerges at the workstation when someone shows a screen and says 'here I normally put next Monday's date, except for them'. Record the sentence as spoken, with the client's name and reason. A rule rewritten in administrative language loses its exception, the only piece market software cannot reproduce.

The document is the product's memory

In Maestro this document has a name and place: the requirements document, written in French by Victor from Margaux's scoping, reviewed by you, approved with 'Looks good to me' before any code exists. It serves twice. First during construction, when agents refer to it instead of guessing. Second years later: code can be regenerated from the document; the reverse does not work. Taking over existing software begins with that reading before migrating anything.

What you gain by writing it

A new employee learns the business by reading instead of asking twenty questions. A provider estimates from a document instead of a conversation, letting you compare quotes on one basis. When a major client asks to use the tool, you can discuss a contract instead of digging through code. If you rebuild everything later, previous years' work remains while 2019 code helps nobody. That is where the r/vibecoding owner stands: four years of accumulated decisions in a tool a large group wants, with value concerning those decisions rather than files. What they built can be explained, sold, and recreated elsewhere if written down.

Start with ten lines this week

Take a sheet and write ten rules, one per line, starting with exceptions most often explained to your teams. Date it. Have the order-processing person review it; they will correct three and add two. You will have the first version of your product's memory, already worth more than what your current software contains.