Logic Before Code: How to Make Better Decisions Before Investing

The business situations in this article are fictional illustrations, not accounts of Parikh Advisory client engagements.

A team ships a rule exactly as specified. A customer challenges the result; the system has no exception path because the policy owner never decided what should happen in that case. The code is doing its job. The unresolved business decision is now being made by support under pressure. “Logic Before Code” means making the consequential rules, owners and evidence explicit early enough that implementation can serve the intended outcome.

State the decision underneath the feature

Before writing a requirement, ask what problem is observed, for whom, and what improvement would count. Separate the desired outcome from the proposed screen or automation. A request for an approval dashboard may conceal an unclear approval policy; a request for AI recommendations may conceal inconsistent data. Capture the rule in ordinary language and test it with a real case.

Walk the awkward case

Describe the trigger, inputs, eligibility, decision, notification and appeal or correction route. Then change one assumption: the document is missing, the customer disputes a record, or the reviewer is unavailable. Who can override a result and on what evidence? If the team cannot answer, that uncertainty belongs in the decision log, not inside a developer’s guess.

Compare intervention sizes

The best next step may be a policy clarification, training, a manual pilot, configuration, a purchased tool or custom development. Compare them against the same measurable outcome, risk and ongoing effort. A manual trial can reveal exception volume before automation, provided it respects privacy and applicable controls. A large build is justified when the rule is stable enough and the value of scale exceeds the ownership burden.

Connect learning to release

Assign a decision owner and an operating owner. Write acceptance examples that cover the common path and meaningful exceptions. Agree what signal would cause the rule to be revisited after launch. The phrase does not imply analysis should continue indefinitely; decisions can be time-boxed. It means the team knows what it is encoding, why, and who can change it when evidence improves.

The next decision

Take one contested rule into a working session with its policy owner and write down the exception before asking engineering to implement it.

Source note: GOV.UK Service Manual, writing user stories and acceptance criteria. Examples are illustrative; the linked source supports the decision method, not the hypothetical business.