Services are data, not code

A good bookkeeper knows a thousand small things. That paying a person is different from paying a company. That a round number to a name you have never seen is worth asking about. That a laptop might be an expense or might be an asset, and only the owner can say which.

None of that is written in a manual. It lives in their head.

So how does it get into software? Usually like this: the bookkeeper explains it to a programmer. The programmer writes down roughly what they heard. That rough version ships. The person who actually knew the job is now three steps away from it.

A restaurant is not its oven

Two restaurants can have the exact same kitchen and serve completely different food. The oven is not what makes them different. The recipes are. The standards are. The person calling service is.

Most software that tries to automate a service builds the oven, then bakes one menu into it permanently. We split them apart.

The kitchen is fixed: doing the work, keeping client data safe, talking to customers, taking payment. That part is the same for everyone. A service is the recipe — what this business does, how it decides things, what good looks like, what it costs.

And a recipe is just writing.

Here is the test. Can you add a brand new service, for one customer, today, without a programmer? If not, you have not really separated anything.

What a service turns out to be

Once you stop building them as software, a service comes down to four things — and all four are things you write, not code:

• What jobs there are. Close the month. Chase this invoice. Screen this candidate.
• What finished looks like. Not "it's done" — the specific things that have to be true first.
• The craft. How to decide. When to ask instead of guessing. What never to do.
• What you need from the client to start, and what the work costs.

None of that is engineering. All of it is what an experienced person has and a beginner does not.

Always write down the why

The most valuable files in our whole system are short notes that read like an old hand briefing someone new. And they always say why.

"Ask about the rule, not the transaction" is a fine instruction on its own. It sticks when it comes with the reason:

Asking "how should I file this $48 to Acme Supplies?" gets you an answer once — and you will ask the same thing again next month. Asking "Acme Supplies shows up every month, is that always office supplies?" settles it forever.

A rule without a reason gets dropped the first time it is annoying. That is true of people. It turns out to be just as true of AI.

Where you have to draw a line

Not everything can be writing. If you let it be, you end up with something very flexible and quietly unsafe. So:

Writing decides what the work is. Which jobs, what good looks like, how to judge, what to charge.

Code decides what is allowed. Who can see whose data. What needs a human to say yes. Which keys a job can hold. How often one person can be contacted.

A recipe can ask to use the oven. It can never hand itself the keys to the building. That is what makes it safe for a service to be written on the fly — even by the system itself, after talking to a business owner. The worst a bad description can do is describe a service badly.

The catch

You lose the safety net. With software, the computer tells you when something does not fit. With writing, a note that nobody hooked up just... does nothing. Quietly. Possibly for months.

We check for that automatically now. It is a boring check and it earns its keep, because that failure is invisible by design.

Worth it anyway. The slow part of automating a service business was never how fast anyone could write software. It was getting what the expert knows into the system without it going through a translator first.