In Death Note, the notebook comes with rules. A lot of rules. The manga spends entire chapters listing them, qualifying them, revealing edge cases. And the whole plot rests on their exactness: one detail misunderstood and the plan collapses.
It's the best description I know of serious business software.
Since 2024 I've been contributing to a home-care management platform for the UK market. From the outside, the main app looks like a calendar: carers, service users, visits to schedule. "CRUD with a planner."
Two years later, it's the densest product I've worked on.
What "schedule a visit" actually means
Take the most obvious feature: assign a carer to a visit at a service user's home, Tuesday at 9am.
Here's part of what has to be checked:
- Is the carer available? Not merely free in the calendar — not on leave, not signed off sick, within contracted hours.
- Do they hold the required qualifications? Some tasks require certification. Some certifications expire.
- Is travel time from the previous visit realistic? A visit at 9:00 and another at 9:15 ten kilometres away is a schedule that manufactures structural lateness.
- Does the service user have preferences or restrictions? Carer gender, spoken language, a documented refusal of one specific person.
- Does this assignment create an hours breach under employment law?
- Does it generate enhanced rates — night, weekend, bank holiday — that change the cost?
- Is the visit covered by the service user's funding plan? If not, who pays?
Seven families of rules for one drag-and-drop in a calendar. None is optional: each maps to a legal obligation, a financial risk, or the safety of a vulnerable person.
The trap of the prototype that works
Here's how these products go wrong, and it's nearly always the same story.
The prototype handles the happy path. It ships in six weeks, everyone is pleased. Then the real cases arrive, one at a time, each as a ticket:
- "What if the carer calls in sick that morning?"
- "What if the service user is hospitalised for two weeks?"
- "What if we have to prove to the inspectorate who attended when, fourteen months ago?"
- "What if two schedules were created twice by mistake?"
Each case is handled in isolation, by a condition added wherever it hurt least. Eighteen months later the assignment function runs to eight hundred lines, nobody dares touch it, and every fix breaks another.
This isn't a competence problem. It's a model problem: a visit was modelled as a row in a table, when it is a contractual commitment with a lifecycle.
What actually helps
Make rules explicit and named
A business rule buried in an if is a lost rule. Nobody can enumerate it, test it in isolation, or explain to the client why the system refused.
A named rule — CarerQualifiedForTask, SufficientTravelTime, WithinContractedHours — becomes a domain object. It tests alone, it toggles per client, and above all it reports back: when an assignment is refused, you can say which rule blocked it. That's the difference between software you endure and software you understand.
Separate what is true from what is computed
The costliest confusion I see: mixing facts and derivations.
A fact: "the carer clocked in at 9:07." Immutable, timestamped, never recomputed.
A derivation: "this visit counts as 55 minutes of billable time at the standard rate." The result of a calculation, liable to change if the rate card changes.
If you store the derivation without the fact, you can no longer recompute anything when a rule evolves — and it will. If you recompute everything on the fly without ever freezing, you cannot explain an invoice issued eight months ago.
The right answer keeps both: facts as an immutable log, derivations as a dated snapshot carrying the version of the rate card applied.
Accept that correction is part of the domain
In management software, the data is wrong. A carer forgets to clock in. A scheduler picks the wrong service user. A visit is cancelled after being invoiced.
The developer's reflex is to prevent the error. That's an illusion: the error comes from the physical world, not from the interface.
What you need is to tool the correction: who can correct what, until when, with what trace, and what effect on what has already been invoiced. A correction never overwrites — it adds a reversing entry and a new value. That's double-entry bookkeeping applied to software, and it's the only approach that survives an audit.
It's also the feature nobody asks for in the initial specification, and everybody demands after six months.
The current problem: we train for this badly
Here's what strikes me about the state of the profession.
We train developers in technique: frameworks, algorithms, patterns, performance. We barely train them to understand a business.
Yet in management software — and that's the vast majority of software written in the world — the difficulty is almost never technical. It's in understanding the domain. The code that causes trouble isn't the slow code: it's the code that modelled a reality crooked.
The skills that make the difference on these projects:
- Knowing how to interview. Ask "show me how you do it today" rather than "what do you need". People describe their own work poorly; they perform it well.
- Spotting the awkward cases early. The right question in a scoping meeting: "what was the most painful case you had to handle this year?" The answer is worth twenty pages of specification.
- Refusing to code what you haven't understood. A developer implementing a rule they can't explain will produce a bug, with a variable delay.
Artificial intelligence sharpens this imbalance. It writes correct code faster and faster. It does not know that a visit cancelled less than two hours ahead is still billed at 50% under that particular client's contract. That knowledge is written nowhere — it lives in the head of a person you have to go and listen to.
What gains value is no longer writing the code. It's knowing which code to write.
What I check before accepting a domain project
- Can I speak to someone who does the work? Not the sponsor, the user. If not, I decline.
- Is there a regulatory constraint? If so, it structures the architecture and must be known before the first line.
- What happens when it's wrong? If the answer is "we fix it in the database", the project isn't ready.
- Who arbitrates when two rules contradict each other? You need a name, not a committee.
Those four questions have spared me more trouble than any technical choice.
This platform is described on its project page, without confidential detail. If you're carrying business software whose complexity is getting away from you, write to me.