Nobody asked me to build a form engine. React Hook Form exists. Formik exists. Typeform and Tally exist if you want hosted. The rational move is to use what is available and spend your time on something else.
I built one anyway. And then I built a payment SDK in a world where Stripe's SDK is excellent.
Here is what I have learned from shipping tools into categories where people's first reaction is "why?"
The gap is never obvious
When I tell people I built a form engine, they say "but there are already so many." And they are right. But every existing solution sits at one extreme or the other.
On one end: component libraries. You get <TextField> and useForm, and you wire everything by hand. Full control, full responsibility, full repetition on every project.
On the other end: SaaS builders. Drag, drop, hosted, done. Zero control, zero ownership of your form logic.
The middle — a schema-driven engine that renders locally, validates locally, and gives you an artefact you can version-control — was surprisingly thin. Not empty. But nothing I tried worked the way I wanted.
The gap was not "no one has built this." The gap was "no one has built this the way I think it should work."
Scratching your own itch is not a business plan
Building for yourself guarantees one user: you. That is not a product. That is a personal tool.
The transition from "I built this for my projects" to "other people might want this" requires a different kind of work. Documentation. Packaging. A coherent API instead of the one that made sense to you at 2am.
I spent as much time on docs as on code for both FieldCraft and PayKit. Probably more. Because a well-documented tool with a decent API will get adoption. A brilliant tool with no docs will not.
Competing with "good enough"
The hardest part is not competing with bad alternatives. It is competing with good enough. React Hook Form is good enough for most projects. Stripe's SDK is good enough if you only need Stripe.
To earn a migration, you need to be better in a way that matters to the specific developer evaluating you. Not better in general — better for their use case. "Our validation pipeline is more elegant" does not matter. "You can define your entire form as JSON and change it without a deploy" might.
I stopped trying to convince people who are happy with their current tools. Instead, I write for the developer who just hit the wall — who is on their third project rebuilding the same form infrastructure, or who just got told they need to add Razorpay and their Stripe integration is hardcoded everywhere. Those people do not need convincing. They need a solution.
Distribution is the bottleneck
A mediocre tool with great distribution will outperform a great tool with no distribution. That is just true, and it is uncomfortable.
I do not have great distribution. I have a GitHub repo, a docs site, a few blog posts, and npm. That is it. No Twitter following, no conference talks, no viral launch post.
What I do have is patience. Open-source adoption compounds. One person uses it, hits an edge case, opens an issue. I fix it. They tell a colleague. The colleague tries it. Slowly, the user count grows.
Is that fast enough? I do not know yet. But I would rather build something good and wait for adoption than build something average and spend all my time on marketing.
What I would do differently
Start with the docs site before the library. Write the getting-started guide before the first line of code. If you cannot explain how someone would use your tool in five minutes, the API is wrong.
I did this backwards for FieldCraft — built the engine first, docs later. The docs process forced me to simplify the API in ways I should have done upfront. For PayKit, I wrote the docs outline first. The resulting API was cleaner from day one.
The second thing: ship fewer features, earlier. My first FieldCraft release tried to cover every field type I could think of. In hindsight, shipping with ten solid field types and adding the rest based on what people actually needed would have been smarter.
But that is easy to say after the fact. When you are building something no one asked for, there is always the fear that "not enough features" is why no one will try it. So you add more. And more. And eventually you ship. And the features people care about are never the ones you expected.