Thanks to large language model (LLM) enabled chatbots (like the SurveyCTO AI Assistant), anyone can create helpful, working code today. This is greatly empowering in a wide range of fields, including those that rely upon form-based data collection platforms, such as SurveyCTO.
One way that GenAI can help you is in building custom field plug-ins. In SurveyCTO, field plug-ins extend, enhance, or change the appearance and functionality of SurveyCTO’s fields, providing more options for your forms and surveys.
Tip
For further context and ideas for how to use field plug-ins in your data collection, explore this blog post.
Since we introduced field plug-ins, anyone with some web developer experience has been able to customize the UI and functionality of form fields in SurveyCTO forms. Now, thanks to LLMs, the accessibility to creating plugins includes you, regardless of your professional background.
In this guide, I’m going to explain how to approach field plug-in development as a non-developer using an LLM. This is a process I’ve gone through as a business user several times, despite not being a software engineer myself.
Beginner-friendly tips for using GenAI to build field plug-ins
Start here with these points, especially if you don’t have much experience with field plug-ins or LLMs:
- If any part of this guide is unclear to you, ask an LLM for more details 🙂
- Pick an LLM model as a collaborator with a good reputation for writing good code (the models change too often to recommend one).
- I recommend picking a slow-thinking, advanced model over a faster model. I’ve used several, including Gemini 2.5 Pro (for its large context window), and Claude Sonnet 4, given its great reputation among professional developers.
- As you’ve heard by now, LLM outputs will be improved by the quality of instructions you input. In other words, ensure that you’ve provided your LLM with adequate starting context. This will help to improve its performance.
- I talk about this more in my “First Content Prompt” section below.
- Ensure you’re familiar with the ins and outs of field plug-ins from an end user perspective. Make sure you know how to configure one with a form and set its parameters correctly.
- Test a few field plug-ins (see the catalog) to learn some of what’s already possible. You might even find that what you want has already been created!
- Read the developer documentation. An LLM will be doing the work, but you at least need a structural understanding of how field plug-ins work.
- Pick a basic first project with a goal even simpler than your true goal, to get experience.
Tip
For general guidance on SurveyCTO’s field plug-ins for beginners, including how to configure a plug-in with a form, check out another guide I wrote!
A word of caution
While I highly recommend exploring field plug-in development (it can be helpful and fun), you should be aware of the following risks:
- Connecting to online services and resources. While SurveyCTO provides a robust environment for your plug-ins to run inside, connecting to online services and resources could open your form and the data you collect up to online threats.
- API keys and other sensitive data. Field plug-ins that collect to online services may require sensitive resources like API keys or passwords. Do not include these directly inside field plug-in code or form designs, for security reasons.
- Complex projects. While project complexity might be hard to judge before you’ve started developing a technical specification, here’s a good guideline: The more parts, features, and differences from basic SurveyCTO functionality, the more complex and challenging it will be to achieve your goal.
The above are signs that you might benefit from at least consulting a professional software developer during this process, even if you’ll use an LLM to write the code. If the project you have in mind includes at least two of these risks, you might consider hiring a developer, if you have the budget.
First content prompt
To get started, after selecting your LLM, before you ask it for any input or share further details, a prompt like the following can help improve the quality of outcomes.
Drop something like the below in first and then get into specifics.
I would like to get help with a SurveyCTO field plug-in, which is built with HTML, CSS, and JavaScript and adds a new custom field type to SurveyCTO forms. For reference and context, I am including the following:
- Reference documentation for SurveyCTO field plug-ins, which includes all relevant details: https://github.com/surveycto/field-plug-in-resources
- Example sources from the baseline-text plug-ins (template starting points):
You might also share this guide with your LLM partner, too, letting them know that you’re following it.
6 steps to using GenAI to build field plug-ins - a process overview
The development approach discussed in this article works as follows. Remember to consult your LLM partner on each step and ask for feedback. You can even try asking it directly to complete steps for you.
- Create a technical specification
- Create an implementation plan
- Milestone implementation
- Code review and clean up
- Document your plug-in
- Share your plug-in
1. Create a technical specification
Create a detailed design for your field plug-in. A clear plan will be your source of truth, helping you and your LLM partner stick to the best path to reach the goal. A technical specification should cover the following:
- Which baseline field plug-in to start with as a template starting point.
- For example, if the select_one field type is the most similar to what you want to achieve, specify the baseline-select_one field plug-in.
- Which standard SurveyCTO form field features should be kept or discarded.
- Each feature the field plug-in adds.
- Which parameters you’ll offer and how to specify them.
- Which data the plug-in will produce and how it will be stored (using field storage and/or field plug-in metadata).
- Which errors might occur and how the plug-in should handle those cases.
- Similar field plug-ins that have achieved comparable outcomes.
- JavaScript libraries* to be leveraged inside the field plug-in.
Ask one or more LLMs for feedback on the clarity and readiness of your specification and work to resolve those issues.
A note about software libraries
Software languages, including JavaScript, have communities of users who create and share working pieces of code that achieves specific goals. Many of the common interactive and dynamic features of web pages you would’ve seen online are achieved through popular JavaScript libraries.
JavaScript libraries can be used in the same way in SurveyCTO field plug-ins to introduce functionality that’s already been created by other developers. This can save you time and effort.
2. Create an implementation plan
Ask your LLM partner to read your specification and break the project down into proposed development milestones. This is crucial as a non-developer, because you’ll confirm the plug-in is working by testing it, not by reading the code.
An LLM will try to create the whole project for you in one go if you ask it to, but if any parts do not work, you could have a much tougher time fixing it compared to this more conservative approach.
Each milestone should have these features:
- Clear specifications dedicated to that specific milestone.
- Be an incremental step towards the final product.
- Be roughly the same size in terms of level of effort and complexity
- Have observable, testable outcomes that you can confirm as a non-developer by testing it, not by reading code.
An LLM can help you define each milestone. Each milestone is also a natural place to pause and save progress.
3. Milestone implementation
Ask your LLM to implement each milestone, starting with the first one. It should output an HTML, CSS, JavaScript, and JSON file (the component parts of a field plug-in). You need to test each milestone, confirm functionality and behavior, before asking your LLM to implement the next milestone.
Here are some key testing tips:
- If key parts of milestones (or whole milestones) don’t involve SurveyCTO features, you can probably test them fastest using a tool like CodePen.
- Make sure you’re zipping and packaging the field plug-in correctly for testing in SurveyCTO. Study other examples to ensure everything is as it should be.
- Use the field plug-in testing console to test changes. You can make small changes or paste in full replacement HTML, CSS, or JavaScript.
- Your browser’s developer console log can be helpful during testing, if your plug-in project logs confirmatory messages (for example).
- Learn more about the Chrome developer console.
- Make backups after each milestone (or learn to use a version control system like Git).
- Ensure that the code achieves the visual changes, dynamic elements, and refinements to how data is generated or stored (as applicable) before moving on to the next milestone.
Tip
If a particular milestone is proving challenging, producing errors, be patient and work with your LLM partner to resolve them. Also, ask the LLM if it is possible to break the milestone down even further, into smaller, achievable parts.
4. Code review and clean up
Code review is the stage where a developer asks a colleague to read their code and provide feedback. Colleagues on a software engineering team might iterate back and forth about the clarity, correctness, readability, maintainability, and secureness of code. Additionally, a working software project might have redundancies in it and logging that can be removed.
Follow this process:
- Ask your partner LLM to review your code to review stage issues and feedback.
- Ask another LLM to do the same and to be very detailed about the location of problems or concerns.
- Share the feedback from the second LLM with the first one that wrote the code.
- Ask your partner LLM to implement conservative changes based on the review and clean up feedback, while ensuring none of the specified functionality is changed as a result.
- Carefully re-test the plug-in using the specification for reference.
- Iterate with your partner LLM on a project with code review as your last milestone, until everything works exactly as you expect.
5. Document your plug-in
Write a user-facing guide to your field plug-in, describing:
- What the plug-in does
- Expected behavior
- Features
- What data to expect and how to get it
- How to test it
See the README files on GitHub-hosted field plug-ins for examples.
6. Share your plug-in
If your field plug-in solves a problem that you believe other people are likely to have, we recommend that you share it publicly under license that permits free use. Consider a platform like GitHub. In addition, open source licensing that permits modification allows other people to make new and improved versions of your project so that it best fits their own data collection goals.
Publishing your field plug-in is also a great way to show off your achievement! If you’re particularly proud, get in touch with the SurveyCTO team, and we’ll help to share your plug-in with the broader community.
