From User to Contributor: How I Added a Global Feature to Typebot

When I saw my first pull request merge into the Typebot codebase, I felt excited. On May 16, 2025, my code officially became part of Typebot's code. It wasn't a massive overhaul, just a simple "Allow search engines to index" toggle in the settings, but that one little switch symbolized something huge for me: my first ever open-source contribution. As someone who had been using Typebot and dreaming of contributing to open source, this experience was both technically enlightening and personally empowering. In this blog post, I want to share the journey of how I went from being a Typebot user to a Typebot contributor, the technical steps I took to implement the feature, and what I learned along the way. I hope this inspires other developers to take that leap into open source and shows that even small contributions can have a global impact.

Why Typebot and Why Open Source

I chose Typebot for my first contribution because it's a project I already knew and loved. For those unfamiliar, Typebot is a powerful open-source alternative to chatbot builders like Landbot, it lets you visually create interactive conversational forms for things like lead qualification and user onboarding. I had previously used Typebot to build a lead-generation chatbot for a side project, which meant I was comfortable with its tech stack (React, Next.js, and TypeScript under the hood) and knew firsthand the value it provides. More importantly, Typebot has a thriving user community (trusted by hundreds of companies worldwide and boasting thousands of stars on GitHub), so the idea of improving a tool that so many people rely on was highly motivating.

Contributing to open source had been on my bucket list for a long time. I've learned so much from open-source projects throughout my career, and I wanted to give back and be a part of that ecosystem. However, like many first-timers, I found the idea intimidating. Questions like "Where do I start?" or "What if my code isn't good enough?" floated in my mind. By picking a project I was familiar with (Typebot) and a relatively small, well-scoped issue for my first contribution, I set myself up for a positive experience. I wasn't delving into unknown territory; I was building on something I already understood, which gave me confidence to start contributing.

Choosing the Issues & Exploring the Codebase

As a newcomer to contributing, I wanted to find an issue that was approachable but still meaningful. I browsed Typebot's issue tracker for something tagged as a good first issue or enhancement and soon found one that caught my eye: Issue #1123. This issue was about allowing Typebot creators to enable search engine indexing for their chatbots. In simpler terms, Typebot pages were always instructing search engines not to index them (using a noindex meta tag), and a user had requested a feature to make that behavior optional. The issue description explained that by removing the noindex tag when a certain setting is enabled, search engines like Google and LinkedIn would be allowed to crawl and index content. This sounded both useful and straightforward, exactly what I was looking for.

Before writing any code, I spent some time exploring the Typebot codebase to understand where this feature might git in. Typebot's repository is a monorepo with multiple parts: there's a builder app (the dashboard where you create and configure chatbots), a viewer app (which renders the chatbot for end-users), and some shared packages for things like settings schema. The "allow indexing" feature would touch at least two of these parts: the builder (for adding a UI control in the settings panel) and the viewer (to adjust the meta tags on the rendered page). Reading through the project structure and existing code, I identified the key areas I would need to modify. For instance, there was a MetadataForm component in the builder for page settings, and a Seo component in the viewer that handled meta tags for the page. I knew these would be central to implementing the new option.

Adding the "Allow Indexing" Feature

Once I felt familiar with the codebase layout, I got to work on implementing the solution. I broke the task down into a few concrete steps:

1. Adding a Toggle in the Settings UI: I introduced a new switch in the MetadataForm (the settings form in the builder interface) labeled "Allow search engines to index". Typebot's front-end uses reusable components for form inputs, so I used a SwitchWithLabel component for the toggle. I wired it to the metadata state so that toggling it would update a property (let’s call it allowIndexing) in the chatbot’s metadata settings. This involved adding an event handler to update the state when the switch is flipped and ensuring the switch reflects the current value (on or off).
2. Extending the Metadata Schema: I needed a place to store this new setting. In Typebot's code, chatbot settings are validated and managed via a schema (using Zod). I added a allowIndexing field to the metadata schema definition, as an optional boolean value. By marking it optional, we ensure that older Typebots (which don’t have this field saved) would still load without issues, defaulting to the previous behavior (no indexing).
3. Updating SEO Logic in the Viewer: With the front-end and data model prepared to handle the new setting, I moved to the viewer side. The viewer’s Seo.tsx component was responsible for injecting the appropriate <meta> tags in the page head. Originally, it always added a <meta name="robots" content="noindex"> tag to prevent indexing. I modified this logic to make it conditional: only add the noindex tag if the new allowIndexing flag is false or unset. In other words, if a Typebot owner enables "Allow indexing" for their bot, the rendered page will no longer include the noindex meta tag – thereby inviting search engines to index it.
4. Adding User-Facing Text: I added a clear label and tooltip for the toggle so users would understand what it does. In the English locale file, I defined "Allow search engines to index" as the label and wrote a short description as the tooltip, explaining that enabling this will remove the noindex tag and allow services like Google to crawl the page. (Initially, I added these for a couple of other languages as well, but I learned during code review that I should only include the English text and let the project’s translation platform handle the rest – more on that shortly.)
5. Testing the Changes: With coding done, I compiled and ran the Typebot app locally to test my work. I created a sample bot, toggled the new "Allow indexing" switch on and off, and checked the page source in the browser. Sure enough, when the switch was off (default), the page included the <meta name="robots" content="noindex"> tag, and when I turned the switch on, that meta tag disappeared. Everything worked as expected, and the feature behaved exactly as intended in the local environment.

After implementing and testing, I opened a pull request on GitHub with the changes, linking it to the original issue. I wrote a detailed description in the PR, explaining what the feature does and which files I touched, and even included the above screenshot for clarity. The project maintainer reviewed my PR, and I was glad to see that there were no major technical flaws. He did request a couple of minor changes: one of them was about the translations. I had taken the initiative to add French and Portuguese versions of the label and tooltip (since I noticed those locale files in the repo), but the maintainer informed me that new code should only provide an English translation, as they use a service called Tolgee to handle other languages automatically. This was a great tip that wasn't obvious to me initially. I promptly removed the extra translations and also cleaned up an unused import that the reviewer pointed out. With those small fixes in place, my PR was approved and merged.

From Nerves to Pride

Looking back, the whole experience was incredibly positive. It’s hard to put into words how validating it felt to see my code become a part of a project I admire. This was my first time contributing to open source, and I'll admit I was a bit nervous going in. Would I understand the code? Would the maintainers accept my changes? Those worries faded as I dug into the work. The codebase was well-organized and, thanks to my prior familiarity with Typebot’s functionality, I could follow along without feeling lost. By the time I submitted my pull request, I was confident in my solution.

When the maintainer merged my code, I felt a surge of accomplishment. A simple toggle switch might sound trivial to some, but to me it meant that people all over the world would be using a feature I added. I find that incredibly motivating – the idea that a marketer in London or a teacher in Sydney using Typebot could click that "Allow indexing" switch and benefit from it. It's a tangible reminder of why I love software development: a few lines of code written in my room can have an impact on countless users I’ll never meet. That sense of global impact is both humbling and exciting.

This contribution also taught me a lot about the open-source process. I learned how important it is to communicate your changes clearly (my detailed PR description and screenshot helped the review go smoothly), and that maintainers are often quite supportive and helpful. The small bit of feedback I received on translations taught me something new about how large projects manage localization. It was a collaborative feeling – like I was working with the maintainer, not just throwing code over a wall. Overall, the experience boosted my confidence. It demystified the idea of contributing to "other people's code" and showed me that open-source projects are not some exclusive club of genius programmers – they're communities of people who are passionate about improving the tools we all use.

Advice for First-Time Contributors

If you’re reading this and considering making your first open-source contribution, here are a few tips from my experience:

• Start with a Project You Use: It’s much easier to contribute to a project when you understand what it does and why it matters. If you already use a tool (like I used Typebot), you’ll have context that helps you navigate the code and identify valuable improvements.
• Pick a Manageable First Issue: Look for issues labeled "good first issue" or minor feature requests/bugs that match your skill set. Starting small is fine, it’s ideal. My contribution was small in code changes, but still meaningful to users. Completing a small scope successfully will build your confidence for bigger contributions.
• Read the Contributing Guidelines: Most projects have a CONTRIBUTING.md file or docs for new contributors. Give these a read, they often contain instructions for setting up the dev environment, coding style guidelines, and other project-specific conventions. (In my case, I learned some guidelines indirectly through code review, like the translation rule. Reading documentation upfront can save such rework.)
• Don’t Hesitate to Ask Questions: If something is unclear, be it how to run the project or details about the issue, don’t be afraid to reach out (via the project’s chat channel, discussion forum, or even commenting on the issue). Open-source communities are generally welcoming, especially to those showing initiative to contribute. A polite question can quickly clarify things that might otherwise stall you for days.
• Test Your Changes: Before submitting your code, make sure it solves the problem without breaking anything else. Run the project, try to replicate the scenario, and see that your fix or feature works as intended. If the project has automated tests, run them. This gives maintainers confidence that your contribution won’t cause regressions.
• Be Open to Feedback: Code reviews are a normal part of open source. If a maintainer or other contributors suggest changes, don’t take it personally; it’s all about making the project better. Incorporate the feedback and use it as a learning opportunity. In my case, the feedback was minor but valuable; it made me appreciate the importance of following project norms.
• Stay Persistent and Enjoy the Process: Sometimes open-source contributions can take time – maintainers might be busy, or you might need to iterate on your solution. Don’t get discouraged if things don’t move as fast as you’d hoped. Enjoy the learning process. Even if your pull request doesn’t get merged immediately (or at all), you will have learned a ton just by trying. But when it does merge… take a moment to savor the victory!

What’s Next?

Now that I’ve got a taste of open source contribution, I’m eager to continue. I plan to keep contributing to Typebot – there are always new features to build and bugs to fix, and I’d love to deepen my involvement in a project I find useful. I might also explore other projects in the future, especially those that I use regularly. This experience showed me that contributing to open source is not as intimidating as it seems. It’s a fun and rewarding way to sharpen your skills, collaborate with other developers, and give back to the community.

The "Allow indexing" feature was just one small addition, but it’s the first of many I hope to make. Open source has a way of drawing you in – once you see your work out there helping others, you want to do it again. I’m excited for what comes next on this journey, and I encourage anyone who's on the fence to take the plunge and contribute. You might be surprised how much you grow from a few lines of code.