Over the past 14 months, we’ve had 100+ in-depth conversations with developers and product teams building SaaS products that needed one common thing: PDF form capabilities. These were not casual chats—they were real discussions with engineers deep in the weeds of PDF workflows, integrations, and the endless quirks of legacy PDF tech. For most, the goal at hand was to build (or buy) a PDF solution to build, fill, and view PDF files inside their applications. The kicker here, was they didn’t want something that looked or felt foreign to their product. Being Joyfill is natively embeddable and customizable, it was one of the desirables that initiated these conversations.
As one of the founders of Joyfill, these conversations became a treasure trove of insights. Ones that we found might be very helpful to many developers. They shaped how we think about PDFs, why developers are frustrated, and where the industry needs to go. Most importantly, they shaped how we’re building Joyfill v2.
So, here are the most common takeaways and lessons we learned from those conversations. I hope they help accelerate your builds.
Lesson 1: JSON-first workflows make pre-filling and extracting data effortless
In nearly every conversation, developers were frustrated by how difficult it was to populate and extract data from PDFs. “We just want to treat the form like a JSON object,” one dev told me. Another said, “I shouldn’t have to reverse-engineer a PDF to insert a first name.” The desire was clear: a schema-driven way to interact with fields like any other part of a web app.
The best approach we’ve seen is a JSON-first form model—where every field has a stable ID, and form state lives in a clean, structured object. It makes pre-filling fields and capturing updates feel like working with any modern UI state. If you’re building or choosing a PDF tool today, lean into this structure—it saves you from brittle workarounds and opens the door to automation, analytics, and scalable form workflows. With Joyfill, this is easy because everything centers around our “JoyDoc”. Which is JSON.
Lesson 2: Data sovereignty must be a first-class feature
Data ownership came up in almost every conversation. Many teams work in industries—finance, field service, healthcare, government—where storing user data in third-party clouds isn’t always an option or preference.
Modern PDF SDKs should offer both managed and self-hosted data options. The ability to intercept form payloads and store them in your own system isn’t just a nice-to-have—it’s a requirement for teams with compliance needs or strict data policies.
By default, Joyfill stores data in our cloud for convenience. But for teams needing full control, we built a self-hosted data mode. In this mode, you handle the JSON payloads entirely within your own infrastructure, giving you the compliance and control you need.
Lesson 3: Self-hosting is about control and peace of mind
Some developers asked, “Can I just spin this up in Docker and be done?” The answer is: not exactly—but you can achieve the same outcome.
While we don’t provide a single Docker image, our self-hosted data mode gives you the ability to keep all data handling on your side. As mentioned above. For rendering PDFs in your own environment, you can pair the Joyfill Export SDK with a headless browser like Puppeteer or browserless. This approach keeps rendering and export pipelines under your control without tying you to any specific cloud service.
Lesson 4: Customization isn’t a nice-to-have—it’s table stakes
No two SaaS apps look the same, and developers want their PDFs and UI to match their brand seamlessly. That includes theming, branding, and disabling or enabling UI elements at a granular level. Developers should be able to control what users see and how it looks—down to the font, button visibility, and interaction settings.
Joyfill supports theming through two powerful props in React:
- fieldOptions: Define draggable field types with custom styles, default values, and icons.
- fieldSettings: Fine-tune UI elements—disable certain style options (like font size), hide titles, control upload/delete buttons, and more.
This flexibility ensures the PDF solution feels like part of your product, not an external 3rd-party widget.
Lesson 5: Smart PDF forms require built-in validation and logic
Form validation was non-negotiable for nearly every team. Developers wanted not only required fields but also conditional logic to make PDF forms dynamic and user-friendly. Many struggled with brittle validation logic—especially in multi-step flows or mobile forms.
PDF tools need to support native validation and conditional logic, ideally built into the schema or SDK. Whether it’s required fields, field visibility based on answers, or section-level rules, this logic is crucial for real-world use.
Lesson 6: Localization needs to be possible—even if not automatic
Global products need localization, and several teams asked about multilingual support. While Joyfill doesn’t yet offer built-in localization or automatic language switching, you can still localize manually by constructing JoyDoc templates and field labels in any language. This gives you the flexibility to meet international requirements today while we work toward native i18n solutions in the future.
Lesson 7: Fine-grained UI control makes the difference
Finally, developers wanted to control exactly what their users could see and do in the PDF experience. They wanted to control the entire user interaction model. Some needed strict read-only modes for audit scenarios. Others wanted to disable editing features like uploads or deletions. In these cases, “default behavior” wasn’t good enough.
To meet these needs, tools should offer fine-grained control over form interactivity. This includes configurable modes—like edit, fill, or read-only—as well as toggles for individual UI elements at the field, page, or document level. Developers want to tailor the form experience to specific roles, stages, or workflows—without having to fork the library or hack around the defaults.
The Joyfill PDF SDK gives you this flexibility with two mechanisms:
- The mode prop: Switch between edit, fill, and readonly modes.
- fieldSettings: Enable or disable specific UI elements at the file, page, or field level—like hiding upload buttons, style controls, or delete actions.
This level of control ensures the user experience matches your exact use case.
The Big Takeaway: The pair of simplicity, extensibility, and control wins
Talking to over 100 developers taught us that building with PDFs isn’t just about generating documents—it’s about owning the data, controlling the experience, and removing legacy complexity.
Aside from the technical takeaways, many of the questions we receive are general can-you-do PDF questions, but a significant number center around the specific use cases products are trying to solve. For example, how to implement a PDF form filler, an e-signature solution, or a full multi-step data input workflow.
Beyond feature-specific questions, the focus is often on how to actually implement the product experience. The conversations become very scenario-driven. In many cases, we find ourselves guiding users through the thought process of solving their problem with Joyfill (or other libraries for that matter) — not just explaining features, but helping them envision the full solution.
At Joyfill, these conversations directly influenced how we’re approaching v2: a simpler, more extensible SDK that puts developers in control of all the pieces. If you’re building a SaaS product and fighting with PDFs, know this: it doesn’t have to be painful. Let’s talk — we are happy to lend a hand.
We’re solving PDFs for developers—one conversation at a time. On to the next 100…
Top comments (0)