Interaction logic is going through the same revolution content went through a decade ago. Dynz is to the rules of your product what headless was to content: written once, structured, and readable by anything.
A decade ago, content lived inside templates. Every page owned its own copy of the words on it, and every new channel meant rewriting those words into a new presentation layer. It worked — right up until mobile arrived. Suddenly content had to render on screens the CMS had never imagined, and the workaround economy collapsed. The answer was to pull content out of the page entirely: structure it, give it an API, and let any channel read from the same source of truth. We called the move headless, and it quietly changed how digital products are built.
The rules of your product — the validation, the conditions, the flow, everything that decides what a user can enter and what happens next — are still living the way content lived in 2013. They're welded to the screens they were built for, duplicated across frontend and backend, and illegible to anything that isn't a browser.
Dynz exists to make the same move for interaction logic. Write the contract once. Treat it as the source of truth. Let the interface, the server, and any agent that comes along read from the same definition.
You're building a product for a reason. Maybe it's an onboarding flow that needs to convert. A checkout that can't afford a single dropped customer. An application form where every wrong field costs you a real user. Forms aren't an afterthought — they're where your product actually meets the people using it, and they're where the coupling between logic and screen hurts first and most.
So forms are the wedge. But the pattern you'll see in them runs through every interactive surface you own.
The frontend needs validation so users get a friendly nudge when something's off. The backend needs validation so nothing dangerous gets through. Same rules, two implementations, two languages, often two teams. Every rule change has to land in both places to stay in sync — and the bigger the surface area, the more there is to keep aligned. Content teams used to copy the same paragraph into five templates. This is the same disease, wearing different clothes.
A field gets added on the server. A field gets removed from the form. A check gets tightened in one place and not the other. Each change is small and reasonable on its own. Over time, the gaps between the two sides become their own kind of complexity — one that's invisible until something downstream depends on the two staying perfectly aligned. Two copies of the truth never stay identical. They only stay identical so far.
The rules of the form live inside the form. If you want to expose those same rules to a chatbot, a voice assistant, a partner's API, an AI agent — there's no clean way to do it. The logic was written to drive a UI, not to be read by anything else. So the form stays trapped inside the channel it was born in, exactly the way content used to be trapped inside the page.
Why did this field appear? Why is the submit button disabled? Why did this user get this error and not that one? The answers exist in code, but they aren't legible from the outside. There's no way to ask the form what it expects — only to poke at it and see what happens.
Most product teams reach for a component library and ship. And that's the right call most of the time — drift, duplication, and opacity aren't acute injuries, they're a chronic ache. None of them hurt badly enough on a Tuesday afternoon to justify rebuilding how your forms work. The workarounds are cheaper than the rebuild, and the rebuild has no obvious payoff.
The honest answer: the pain is real, but it's diffuse.
Content had the same chronic ache for years. Nobody rebuilt their CMS because copy-pasting between templates was annoying. They rebuilt it when a new class of consumer showed up that couldn't read the old format at all.
That consumer has arrived again.
The moment you try to put an AI agent in front of your product, the chronic ache becomes acute.
An agent can't read your interface. It can't infer that this field is required when that other field is set to "business." It needs the contract — explicit, machine-readable, exposed. And when you go looking for that contract, you discover what's been true the whole time: it doesn't exist as a single thing. It exists as fragments scattered across the codebase, working together by convention rather than by design.
This is the same forcing function mobile was for content. A new channel arrives that cannot parse the presentation layer, and whatever was welded to that presentation layer has to be extracted into structured, addressable data. It happened to words and images then. It's happening to rules and flows now.
LLMs didn't create the problem. They made it worth solving. Forms only had to work for humans, in browsers, on screens. Now they need to work for users and for agents, in the interface and over an API, today and in whatever channel comes next. The old approach got you here. It won't get you there.
Dynz takes the headless principle and applies it to interaction logic. In practice, that means three things — and each one is the inverse of a problem above.
{
"form": "onboarding",
"fields": [
{ "name": "accountType",
"type": "enum",
"options": ["personal", "business"] },
{ "name": "vatNumber",
"type": "string",
"required": { "when":
{ "accountType": "business" } },
"pattern": "^NL[0-9]{9}B[0-9]{2}$" }
]
}A single, declarative definition of your form: the fields, the types, the validation rules, the conditions that show and hide, the steps and how they connect. It's data, not code welded into a component tree. This is your source of truth — the thing that, today, exists only as fragments.
The same contract is evaluated by the same logic on the client and on the server. The friendly nudge in the browser and the hard stop at the API come from one definition, so they cannot drift, because there is nothing to drift between. Rules get written once and land everywhere at once.
Because the contract is data, it isn't reserved for your UI. A web form renders from it. Your API validates against it. An agent can fetch it, understand exactly what's required and why, fill it correctly, and be told precisely what's wrong when it isn't. The same is true for a partner integration, a voice interface, or a channel that doesn't exist yet. And because everything reads from the contract, everything is finally inspectable — you can ask the form what it expects instead of poking at it to find out.
Unlike validation libraries and form builders, which help you build a screen, Dynz defines a contract that screens — and servers, and agents — are built from. That's the difference between a better form and a headless one.
Headless content sounded like over-engineering until it was obviously the only way to do it. We think interaction logic is at the same inflection point. The products that treat their rules as a contract will meet the agent era already fluent in it. The ones that don't will be translating, screen by screen, for years.
Write the contract once. Let everything read it. That's the whole idea — everything else follows from taking it seriously.
Write the contract once.
Let everything read it.
Headless interaction logic. Written once, structured, readable by anything.