When Business Rules Change Weekly: Why Logic Shouldn’t Live in Code

A multi-service firm’s intake system serves multiple service lines — each with different questions, different required fields, different scoring criteria, and different CRM mappings. When those rules are hardcoded, every change follows the same path: a stakeholder requests a modification, a developer implements it, QA tests it, and operations deploys it. A one-line label change takes the same process as a feature release.

For the first few months, this is tolerable. By month six, the change requests stack up faster than the development team can process them. The system built to eliminate bottlenecks becomes one.

The underlying mistake is treating business configuration as application code. They have different change frequencies, different owners, and different risk profiles. A developer should own the intake engine. An administrator should own what the engine does.

We separated the intake engine from its configuration by introducing a metadata layer we call Blueprints. A Blueprint defines everything about a service line’s intake behavior: which questions are visible, what labels they display, which fields are conditionally required based on previous answers, how responses map to CRM fields, and how responses are scored for prioritization.

Blueprints are stored as structured data, not code. An admin edits them through a dedicated configuration interface — toggling question visibility, changing labels, adjusting required-field conditions, and remapping CRM destinations. Changes take effect immediately. No deployment, no developer, no QA cycle for configuration changes.

The intake engine reads the active Blueprint at runtime and renders accordingly. The engine code changes only when the engine’s capabilities change — a new question type, a new scoring mode, a new integration. The business rules expressed through those capabilities change through Blueprints, on the admin’s schedule. (The system this pattern runs inside: three portals, one backend.)

Scoring is the most powerful example of the pattern. The firm’s scoring criteria evolve as they learn which intake characteristics predict successful outcomes. Hardcoded scoring means every insight requires a deployment to act on.

We built three scoring rule modes — binary (yes/no criteria), threshold (numeric cutoffs), and option-weight (scored selections) — each configurable through the admin interface. An administrator defines which intake responses contribute to the case score, what weight each carries, and what thresholds trigger routing actions like priority flagging or specialist matching.

When a new service line opens, the administrator creates a new Blueprint with its own scoring matrix, question set, and CRM mappings. The intake engine handles it without modification. When scoring criteria change — and they always change — the administrator adjusts weights and thresholds directly. The feedback loop from insight to action shrinks from weeks to minutes. What that agility looked like for the firm: the intake story.