Build the engine behind repeated work

A quoting rule copied into three tools becomes three rules waiting to drift apart. A shared engine can keep that behavior consistent across the website, internal application and partner API.

Consistency is useful only when the underlying decisions should be the same. An internal estimate and a binding customer quote can look similar while serving different purposes. Centralizing them without preserving that distinction creates a very efficient way to apply the wrong rule everywhere.

Share the meaning, then the code

Two teams may calculate a margin differently because one is forecasting and the other is reporting completed work. Before treating the difference as duplication, ask what decision each calculation supports.

A shared engine needs a stable responsibility: calculate this result from these inputs under this version of the rules. Similar-looking tasks can share lower-level functions while keeping their different policies explicit.

AI can help discover repeated logic or implement a common service. The business still has to decide which differences are accidental and which are meaningful. The most valuable part of the engine may be that agreement, preserved in examples and tests so later improvements do not erase it.

Make inputs explicit

An engine should receive the information needed to do its work and identify what is missing. Avoid silently borrowing assumptions from whichever screen happens to call it. If a calculation depends on a rate, date or policy version, that dependency should be visible.

Define examples with expected results. Include boundary cases and cases that should be refused or sent to a person. These examples become a common language between the business and the engineering team. They also make later changes easier to evaluate.

Preserve an explanation

People may need to understand why an output was produced. A quote can include the inputs and rate version used. A matching process can record which constraints excluded an option. A report can identify its source period and data status.

This does not mean exposing every implementation detail to every user. It means preserving enough context for a responsible person to investigate a result. A number without its assumptions can be difficult to trust and expensive to correct.

Separate processing from side effects

Calculating a proposed result and applying that result to live records are different steps. Keeping them distinct can support preview, review and safer testing. It also makes it easier to handle a repeated request without repeating a consequential action.

If a job can take time, plan its waiting, running, completed and failed states. Decide how it can resume after interruption. The Google SRE chapter on monitoring distributed systems offers an external reference for making service behavior visible; the monitoring for a small engine should remain proportional to its importance.

Decide who owns change

Business rules will evolve. Name who approves a change, who implements it and how dependent tools are checked. Keep the old examples so a new requirement does not accidentally break an established one.

We would start by asking which recurring capability is valuable enough to become shared infrastructure. Some rules belong in a simple configured tool. Others justify a dedicated engine. APIs explains how other software can use that capability, while change control addresses how to improve it responsibly.