FormWork was not the result of a single idea or a sudden insight. It grew out of a pattern we kept encountering across different projects, teams, and industries.
Between us, Simon and Andrius, we have spent many years building web applications where forms were not incidental. They were central to how the system worked. Applications, onboarding flows, internal tools, operational systems. In all of them, forms were how rules were expressed, data was captured, and processes were initiated.
Over time, we noticed that forms were consistently where complexity accumulated.
The Problem We Kept Running Into
At the start of a project, forms rarely seem like a risk. You define a schema, add some validation, and move on. Most tools handle this stage well.
The issues tend to appear later.
Requirements change. Fields are added. Conditional logic grows. Submissions need to trigger workflows. Old data still needs to make sense after the form evolves. At some point, people start hesitating before changing a form because they are unsure what it might break.
We encountered this pattern repeatedly, regardless of the stack or the domain.
Why Existing Tools Fell Short
We have used a wide range of form builders, from lightweight hosted tools to heavy enterprise systems. Each came with its own strengths and trade-offs.
What none of them handled particularly well was the transition from a form being a simple input mechanism to it becoming part of the application’s core logic.
Logic was often fragmented between frontend code, backend validation, and custom glue. Versioning was either absent or implicit. Workflows were treated as side effects rather than explicit concepts. Over time, the form configuration became difficult to reason about, especially for people who were not involved in the original implementation.
At that point, teams often resort to workarounds or custom code. In some cases, they rebuild large parts of the system themselves.
We have done that too.
The Cost of Building It Yourself
Building a custom form system can be the right decision. It gives you full control and can be tailored precisely to your needs.
It also comes with long-term costs that are easy to underestimate.
Once you own the form engine, you also own schema evolution, data migration, validation logic, conditional rules, workflow execution, performance concerns, and developer onboarding. These problems do not go away after the initial build. They resurface every time requirements change.
We found ourselves solving the same set of problems repeatedly, in slightly different ways, across multiple projects.
The Decision to Build FormWork
FormWork is our attempt to address that pattern directly.
Instead of treating forms as a peripheral concern, we designed the system around the assumption that forms can become long-lived, complex, and central to an application’s behaviour.
That meant making certain architectural choices explicit from the start. Keeping logic on the backend. Treating forms as schemas rather than UI state. Making versioning a first-class concept. Modelling workflows as part of the system, not as an afterthought. Supporting multiple levels of nested repeatable field groups.
These decisions were shaped by practical experience rather than theory. Each one reflects a failure or limitation we have encountered in production systems.
Who We Are Building This For
FormWork is not intended to replace every form builder.
It is for developers, agencies, and teams who already know that forms can become critical infrastructure. Teams who have learned, sometimes the hard way, that changing a form is rarely a trivial act once an application matures.
If your forms need to evolve safely, remain understandable over time, and support real business logic, then FormWork is built with those pressures in mind.
Why We Are Taking Our Time
A system like this needs to be dependable before it needs to be impressive.
We are deliberately focusing on correctness, clarity, and long-term flexibility rather than speed of expansion. These qualities are not always visible at first glance, but they determine whether a platform remains usable after years of real-world use.
FormWork exists because we wanted a form platform that we would trust in our own projects.
That is still the standard we are holding it to.
— Simon & Andrius