The mental model that forms are always components has quietly become orthodoxy in React development. We think that is a limitation, not a truth. The real question is not whether to use React Hook Form or Zod or React Query, those tools are excellent at what they do, but whether your form is actually a user interface or whether it has quietly become a rule engine wearing a UI costume.
Here is what that distinction means in practice. A UI form collects input, validates boundaries, and submits data. It is ephemeral: the user fills it, the server receives it, and the form disappears. A rule engine, by contrast, persists logic. It evaluates conditions, applies transformations, and makes decisions that ripple across a system. When you build a form that computes pricing tiers, enforces eligibility gates, or dynamically reshapes itself based on prior answers, you have crossed the line from UI into rules. The stack you choose should reflect that difference. If your form is a rule engine, treating it as a collection of components will generate complexity that no validation library can fix.
The developers we talk to often discover this boundary only after pain. They build a form that starts simple, name, email, a dropdown, and then someone asks for conditional fields. Then branching logic. Then calculated outputs. The component stack groans under the weight of what is actually a decision tree. The solution is not a better hook or a stricter schema. It is recognizing that some forms are not forms at all. They are rule engines that happen to render as fields. Choosing between UI and rule engines means asking yourself one honest question: does this form produce a result, or does it produce a decision? If the answer is the latter, you need a different architecture.
We believe the most practical move is to separate the rule engine from the UI layer explicitly. Keep React Hook Form and Zod for what they are good at: fast, type-safe input handling. But isolate the conditional logic, the computed values, and the branching rules into a dedicated engine that the UI merely observes. This does not mean more code. It means clearer boundaries. The form stays a form. The rules stay rules. And when someone inevitably asks for a new condition next sprint, you change the engine, not the components.
That is the concrete choice: build a form that thinks, or build a form that collects. The stack you use matters far less than the question you ask first.