# Bhavya Verma — full portfolio context - Role: product engineer, developer experience - Website: https://beebombshell.com - Location: Remote - Availability: open for chats ## About I'm Bhavya, a product engineer working on developer experience, which is a fancy way of saying I care a lot about the first ten minutes with a tool. I started at early-stage low-code startups, where the team is small and the surface area is everything. I like the spot where technical meets creative, and I'm good at explaining either one to the other. Outside work: open source, mentoring (20+ women and non-binary folks into their first contributions so far), and X, where I post views nobody asked for. I'm a product engineer working on developer experience, which is a fancy way of saying I care a lot about the first ten minutes with a tool. I started out at early-stage low-code startups, where nobody has a job title for what you're doing and the only rule is "make it work, then make it nice." I'm happiest where the technical meets the creative, and I'm unreasonably fond of explaining either one to the other. Open source is where I learned most of what I know, so I give it back. I've helped mentor 20+ women and non-binary folks into their first contributions, and I'd do it again tomorrow. I'm bad at sitting still. When I'm "off", I'm usually on X, sharing views nobody asked for. ## Projects ### [brilliant](https://beebombshell.com/work/brilliant) (2026) An AI calendar that sits on top of Google Calendar. Schedule, manage, and reorganize events by just talking to it. Because dragging events around is not a personality. - Stack: TypeScript, Next.js, Google Calendar API, AI Agents - Repository: https://github.com/BeeBombshell/brilliant - Live site: https://brilliant.beebombshell.com An AI calendar that sits on top of Google Calendar. Schedule, manage, and reorganize events by just talking to it. Because dragging events around is not a personality. Built with Next.js, Google Calendar API integration, and natural language schedule manipulation. ### [spotify-now-playing](https://beebombshell.com/work/spotify-now-playing) (2026) A minimalist service that shows what you're listening to on a profile, site, or blog. Yes, it's on the lanyard card. That's the flex. - Stack: TypeScript, Spotify Web API, Edge Functions, SVG - Repository: https://github.com/BeeBombshell/spotify-now-playing - Live site: https://spotify.beebombshell.com A minimalist service that shows what you're listening to on a profile, site, or blog. Yes, it's on the lanyard card. That's the flex. Provides real-time cached Spotify track data via clean SVG embeds and API endpoints. ### [stickle](https://beebombshell.com/work/stickle) (2026) Persistent sticky notes on any webpage, with export to Notion. Sticky notes for the internet. - Stack: TypeScript, Chrome Extension, Notion API, Tailwind CSS - Repository: https://github.com/BeeBombshell/stickle - Live site: https://stickle.beebombshell.com A browser extension that lets you drop persistent, positioned sticky notes anywhere on any webpage, with full export to Notion. Sticky notes for the internet. ### [This site](https://beebombshell.com/work/beebombshell-com) (2026) A monochrome personal system featuring Verlet lanyard physics, 2D canvas stipple morphing, and liquid glass notch nav. - Stack: Next.js, Verlet Physics, Canvas 2D, Tailwind CSS - Repository: https://github.com/BeeBombshell/beebomsbhell-oct'26 - Live site: https://beebombshell.com Case study for this site's own build: Verlet rope physics for an interactive ID badge, responsive canvas stipple particle engine with text-aware dimming, and an adaptive notch navigation that morphs into a liquid glass pill. ### [Community Sharing & Templating](https://beebombshell.com/work/community-templating) (2025) Building a community marketplace for workflows and nodes at BuildShip using remixing, template library, documentation, and node contributions, all deeply integrated into the existing builder experience. - Stack: Work, Product, Architecture, BuildShip - Live site: https://beebombshell.com/work/community-templating ## Overview Community Sharing and Templating was about turning BuildShip from a place where workflows live in isolation into an ecosystem where good work compounds. Users were already building powerful workflows and custom nodes, but there was no structured way to share, document, or reuse them across projects. This project focused on building the foundations for a community marketplace through workflow templates, remixing, documentation, and node contributions, all deeply integrated into the existing builder experience. ## Remix Templates and Workflow Sharing At the core of this system is the idea of remixing workflows. Users can share any workflow using a Remix link directly from the workflow top bar. This generates a public URL that allows others to preview the workflow and clone it into one of their own projects. ![Remix Workflow Preview and Deep Clone Modal](/images/projects/buildship/remix.gif) The remix experience is designed to be frictionless. A user opens the link, selects a target project, and the workflow is deeply cloned without modifying the source. This includes preserving the workflow graph, node configuration, and example values while safely stripping anything project-specific. The Remix Modal handles this entire flow and acts as the primary entry point for sharing workflows publicly. The result is one-click sharing with project-level cloning that feels native to the product rather than bolted on. ## Template Library On top of remixing, I built the Template Library as a dedicated place to discover complete workflows. Templates are presented in a gallery-style interface where users can browse, search, and filter by category such as AI, utility, or database. Each template can be previewed before use and cloned directly into a selected project. ![Template Explorer and Filterable Gallery](/images/projects/buildship/template-explorer.png) The library is integrated with the same project selection and cloning logic used by remix links, ensuring consistency across the sharing experience. This allows new users to get started quickly with production-ready workflow patterns instead of starting from a blank canvas. ## Template Details and Remixing Each template has a detailed view that explains what it does and how to use it. This includes descriptions, README content, and real input-output examples from executions. ![Template Details with Live Execution Examples](/images/projects/buildship/template-details.png) Users can remix templates into their own projects. This required building deep cloning workflows that preserve the workflow graph, node configuration, and example values while removing anything unsafe. I also added internal testing routes to validate templates before they become public. ## Workflow READMEs To make shared workflows understandable, I implemented README support directly within the workflow context. Each workflow can have an associated README page that acts as its documentation. Creating a README is triggered from the workflow top bar using a dedicated hook. Under the hood, this creates a new document in Firestore under the project pages collection, initialized with a structured Markdown template to guide authors. ![Workflow README Embedded in Builder Context](/images/projects/buildship/readme.png) If a workflow is not already organized, the system automatically creates a folder and moves both the workflow and its README into it. This keeps shared templates clean and discoverable. The editor experience is powered by a rich Markdown editor with support for tables, images, code blocks, and interactive Sandpack snippets. Changes are synchronized in real time using a two-way Firestore data flow with debounced persistence to keep edits responsive and safe. ## Community Nodes and Node Library Community sharing extends beyond workflows to the building blocks themselves. The Node Library includes a dedicated Community tab alongside core nodes and personal libraries. This space is designed to surface community-contributed nodes and encourage users to become node makers. ![Node Library with Community Contributions Tab](/images/projects/buildship/community-nodes.png) While the current implementation includes a featured placeholder and call to action, the underlying system supports node submissions, review, and future expansion into a full community catalog. Nodes can be discovered through the same search experience used inside the canvas, keeping discovery close to where users actually build. ## The Developer Experience A large part of this project was about designing for portability and ecosystem growth: - **Frictionless Creation**: Users create workflows and nodes inside their own projects without ecosystem friction. - **Natural Publishing**: Built-in modals make publishing and sharing feel natural and guided. - **Centralized Discovery**: Centralized libraries handle search, filtering, and categorization. - **Seamless Adoption**: Adoption is handled through a consistent project selection flow that automatically manages project limits and resource allocation during cloning. This separation between creation, publishing, discovery, and adoption keeps the system flexible while avoiding tight coupling between community content and core product logic. Community Sharing and Templating laid the groundwork for reuse inside BuildShip. Workflows can now be shared, documented, discovered, and safely cloned. Users can learn from real examples, and the platform has a clear path toward a growing ecosystem of templates and nodes. ### [Object Detection with BuildShip's Google Vision API Template](https://beebombshell.com/work/google-vision-api) (2024) Learn how to implement object detection in your workflows using the Google Vision API template on BuildShip. - Stack: Work, AI, Pipelines, BuildShip - Live site: https://beebombshell.com/work/google-vision-api ## Bringing Computer Vision to Serverless Workflows Computer vision has rapidly become a core capability for modern software, enabling everything from automated inventory tracking and quality inspection to intelligent media moderation. However, traditionally integrating vision models into production applications required substantial infrastructure overhead: provisioning GPU or containerized backend servers, configuring Google Cloud service accounts and SDKs, parsing multi-part payloads, and calculating bounding box coordinate transforms. While building templates and nodes at BuildShip, I wanted to bridge this gap. The goal was to provide an end-to-end, production-ready template that packages Google Cloud Vision's object localization into a visual, low-code workflow that any developer can remix and customize in minutes. ## Architecture of the Google Vision Workflow The template exposes an HTTP endpoint that ingests an image URL, analyzes its contents via Google Vision API, detects objects, and returns both structured JSON metadata and an annotated image with colored bounding boxes and labels. Here is how the end-to-end pipeline operates: 1. **HTTP Trigger (`/detectobjects`)**: The workflow starts with an incoming GET request that takes a query parameter, `imageURL`, pointing to the target image file. 2. **Input Validation**: The URL is validated to ensure it points to a reachable, supported image format (JPEG, PNG, WebP). 3. **Google Cloud Vision Node**: The image URL is passed to BuildShip's Google Vision localization node. Under the hood, this makes an authenticated request to the Google Vision API, executing an `OBJECT_LOCALIZATION` feature query. 4. **Bounding Box Calculation**: Google Vision returns a list of detected objects, each with a localized name, confidence score (`0.0` to `1.0`), and normalized bounding polygon vertices. 5. **Visual Annotation (Canvas / Headless Renderer)**: A downstream node computes the pixel coordinates from the normalized vertices and draws bounding boxes with category tags directly over the original image. 6. **API Response**: The workflow responds with a clean JSON payload containing the detected entities along with the newly rendered annotated image asset. ![Object Detection Workflow Architecture in BuildShip](/images/blog/vision-workflow.jpeg) ## Real-World Use Cases Integrating object detection as an API endpoint unlocks immediate automation opportunities across industries: - **E-Commerce & Inventory Management**: Automatically categorize items from warehouse cameras or seller product uploads, verifying that required items are present before listing. - **Smart Asset Tagging & DAM**: Ingest thousands of marketing assets, automatically tag visible items (e.g., laptops, clothing, vehicles), and index them for rapid internal search. - **Security & Workplace Safety**: Monitor facility imagery for required safety equipment like helmets and vests, triggering instant notifications when safety compliance standards are breached. - **Social & UGC Moderation**: Detect prohibited items or inappropriate objects in user uploads before they are published to public feeds. ## Handling Coordinate Normalization A common gotcha when working with Google Vision API is handling coordinate geometry. Rather than returning absolute pixel values, Google Vision returns normalized vertices where $x$ and $y$ are floats between `0.0` and `1.0`, representing the proportion of the image width and height. By abstracting this coordinate transformation inside the workflow node, consumers of the template do not have to write custom canvas drawing logic. They simply pass an image URL and receive the annotated result ready for downstream consumers. ## Extensibility & Composable Pipelines The true power of this template lies in its composability. Because BuildShip connects visual triggers and nodes seamlessly, you can branch the workflow to: - Store detected object tags directly in **Firestore**, **Supabase**, or **Postgres**. - Trigger alerts in **Slack** or **Discord** if a specific item or anomaly is identified. - Feed the detected labels into **OpenAI** or **Claude** to generate an automated descriptive summary of the scene. You can inspect the full workflow and try out the template directly on [BuildShip](https://buildship.com), or check out the [original post on Medium](https://medium.com/@beebombshell). ### [Human in the Loop](https://beebombshell.com/work/human-in-loop) (2025) Building Human in the Loop workflows at BuildShip using pause and resume, enabling email and Slack based approvals with structured, validated input. - Stack: Work, AI Agents, Slack, BuildShip - Live site: https://beebombshell.com/work/human-in-loop ## Overview This project focused on enabling Human in the Loop workflows in BuildShip by leveraging the platform’s existing pause and resume execution model. The goal was to let workflows safely wait for human input without breaking automation, consuming credits, or requiring complex workarounds. The result was two production nodes: - **Email Human in the Loop**: Delivers approval requests and input forms directly to user inboxes with dynamic resume links. - **Slack Human in the Loop**: Dispatches interactive message blocks into Slack channels or DMs with live response validation. Both allow workflows to pause, request a decision or structured input from a human, and then resume execution once a response is received. ![Slack Human in the Loop Interactive Workflow](/images/projects/buildship/Slack-hitl.mp4) ## The Problem Many real-world workflows cannot be fully automated: - AI outputs need human review and validation. - Critical operations and financial actions require explicit sign-off. - Contextual and subjective decisions need domain expertise. Before this work, users had to either stop automation entirely or build fragile external approval systems. The requirements were clear: - Allow workflows to pause safely for human input. - Resume cleanly with validated, type-safe data. - Keep the entire authoring experience native to BuildShip. ## Leveraging Pause and Resume BuildShip already supports pausing workflows using an underlying pause and resume mechanism. My work focused on applying this capability to real communication channels and designing a clean developer experience around it. When a Human in the Loop node executes, it calls pause and returns a waiting response. The workflow state is preserved, and a unique resume URL is generated. Execution stops until that URL is invoked. This approach avoids long-running execution, polling, or credit usage while waiting. From the workflow author’s perspective, it feels like a natural pause in the flow. ## Response Models Both Email and Slack nodes support two distinct response models: ![Conditional vs Structured Response Models](/images/projects/buildship/hitl-response.png) - **Conditional responses**: Simple approvals or rejections. Authors can customize button labels, and the node returns a clean boolean result back into the workflow graph. - **Structured responses**: Allow workflow authors to define a JSON Schema describing expected input. Human responses are validated against this schema before the workflow resumes, ensuring downstream nodes receive predictable, typed data. This made it possible to collect real structured input from humans instead of unvalidated free-form text. ## Email Human in the Loop The Email HITL node delivers approval or input requests via email. ![Email Human in the Loop Configuration](/images/projects/buildship/hitl-email.png) When the node runs, it calls an internal workflow responsible for sending the email. That workflow handles authentication, template rendering, and attachments. After triggering the email, the main workflow pauses. Emails include links or buttons wired directly to the resume URL. When a recipient responds, the workflow resumes and processes the result. The implementation supports rich HTML templates, placeholder interpolation, and image handling. Images can be external URLs or files that are automatically converted and uploaded to make them publicly accessible. This allowed email-based approvals without requiring users to build separate email infrastructure. ## Slack Human in the Loop The Slack HITL node integrates with Slack using OAuth and delivers requests directly into channels or direct messages. ![Slack Interactive Message Blocks and Action Handling](/images/projects/buildship/hitl-slack.png) When executed, the node sends a Slack message built from dynamic blocks and then pauses the workflow. Message metadata and resume details are stored in Firestore to preserve state across the pause. When a user interacts with the message, the input handler retrieves the stored context, validates the response, updates the Slack message to mark it as completed, and resumes the workflow. This avoids duplicate responses and gives clear visual feedback inside Slack. ## State Management and Validation Slack-based HITL requires explicit state management. Message timestamps, channel IDs, response schemas, and callback URLs are persisted so the workflow can safely resume later. - **Structured responses** are validated against the original JSON Schema before continuing execution. - **Conditional responses** are passed through directly as boolean decisions. This ensures that human input does not introduce inconsistent or malformed data into downstream workflow nodes. ## Developer Experience A large part of this work focused on DX rather than raw functionality: - Workflow authors can configure HITL nodes without thinking about low-level callbacks or database storage. - Templates support placeholder interpolation and separate states for pending and resolved requests. - Errors are surfaced clearly when workflows are not in a shippable state or when integrations are misconfigured. - The pause itself does not consume runtime credits, making long-running human approvals practical. ### [Workflow READMEs](https://beebombshell.com/work/readme) (2024) Building Workflow READMEs at BuildShip using Firestore, real time sync, and a rich Markdown editor to keep documentation close to execution. - Stack: Work, DevTools, Documentation, BuildShip - Live site: https://beebombshell.com/work/readme ## Overview As workflows grow in complexity, understanding them becomes just as important as executing them. Before Workflow READMEs, context lived in people’s heads, Slack threads, or external docs that quickly drifted out of sync. This feature focused on bringing documentation directly into the workflow itself. Workflow READMEs in BuildShip are implemented as first-class pages that live alongside workflows, not as an afterthought or static text field. ## Why READMEs Needed to Live Inside the Product Workflows are often shared, cloned, or revisited weeks later. Without context, it is hard to answer basic questions: - Why does this workflow exist? - What inputs does it expect? - What assumptions does it make? - How should it be customized? External documentation breaks easily, and inline comments are rarely sufficient. READMEs needed to be tightly coupled to the workflow while remaining flexible and expressive. ## Creating a README READMEs are created directly from the workflow top bar. When a user selects **Create Read Me**, the feature uses a dedicated hook to trigger page creation. Under the hood, this calls a shared atom responsible for creating new pages in Firestore under the project’s pages collection. Each README starts from a predefined Markdown template. This gives users a structured starting point instead of a blank editor, encouraging better documentation by default. To keep projects organized, the system ensures that READMEs and workflows live together. If a workflow is not already in a folder, a new folder is created automatically and both the workflow and its README are moved into it. This small detail prevented a lot of long-term clutter. ## Editing Experience The README editor is built using a rich WYSIWYG Markdown editor (pronounced *"wiz-ee-wig"*, standing for "What You See Is What You Get"), rather than a raw text area. ![Rich Markdown Editor with Sandpack Integration](/images/projects/buildship/readme-mdx.png) Users can write standard Markdown while also having access to richer features such as tables, images, and code blocks. Image uploads are handled through the BuildShip API, so assets remain accessible and stable. For more advanced use cases, the editor supports Sandpack, allowing interactive code snippets to live directly inside the README. This made READMEs useful not just for description, but for interactive teaching and onboarding. All editing logic is centralized in a dedicated `PageEditor` component, keeping the feature modular and extensible. ## Real-Time Collaboration and Persistence READMEs are backed by Firestore and use real-time synchronization. The `usePage` hook handles **two-way data flow**: - It listens for updates from Firestore so multiple users can see changes live. - It persists local edits back to the database with debounced persistence to avoid excessive writes. This allowed READMEs to behave more like collaborative documents than static files, without exposing that complexity to users. ## Routing and Navigation Each README is accessed through a dedicated page route in the v2 routing system. This keeps documentation navigable, linkable, and shareable, while still being clearly associated with a specific workflow. READMEs are not hidden modals or side panels—they are full pages that can grow as workflows grow. Workflow READMEs unlocked several practical benefits: - **Clarity & Reuse**: Shared workflows became easier to understand and reuse across teams. - **Comprehensive Guidance**: Templates could explain setup and customization clearly with interactive snippets. - **Contextual Decisions**: Teams could document decisions close to execution logic. - **Frictionless Onboarding**: Onboarding new users and teammates became significantly easier. Most importantly, documentation stopped being optional. By making it easy and integrated, it became an organic part of the workflow authoring process. ## Writing ### [Run Linux-Targeted Projects on macOS with UTM](https://beebombshell.com/writing/run-linux-projects-on-macos-with-utm) - Published: 2026-10-15T00:00:00.000Z - Tags: macOS, Linux, UTM, Developer Tools Some projects are built specifically for Linux. They may depend on system packages, particular library versions, or tools that behave differently on macOS. Instead of adapting your Mac to the project—or the project to your Mac—you can run it inside a Linux virtual machine (VM) while continuing to use your preferred macOS editor and browser. This guide walks through that setup with a Debian VM in [UTM](https://mac.getutm.app/) and a Django app. The same approach works for any development server that listens on a network port, including Node.js, Rails, and Go apps. ## What you'll build By the end, you'll have: - A Debian VM in UTM that stores the project and runs its development server. - A connection from your macOS editor to the project through SSH or a Samba share. - Access to the app from your Mac's web browser. ```text macOS (host) Debian VM (guest) ┌──────────────────────┐ ┌──────────────────────────┐ │ Code editor │── SSH/SMB ──▶│ Project files │ │ Web browser │── HTTP ─────▶│ Dev server (port 8000) │ └──────────────────────┘ └──────────────────────────┘ connected through UTM's Shared Network ``` ## Terminology | Term | Meaning | | --- | --- | | Host | Your physical Mac. | | Guest or VM | The Debian system running inside UTM. | | UTM | A free, open-source app for running virtual machines on macOS. | | IP address | The VM's network address, which your Mac uses to reach it. | | SSH | A protocol for securely logging in to another machine and running commands. | | Samba (SMB) | A protocol for sharing folders over a network. macOS can mount these shares in Finder. | | Port | A numbered endpoint on a machine. Django's development server uses port `8000` by default. | | Virtual environment (`venv`) | An isolated directory containing a project's Python packages. | ## Prerequisites Before you begin, you need: - A Mac with [UTM](https://mac.getutm.app/) installed. - A Debian—or another Linux—VM that is already installed and bootable in UTM. This [four-minute setup video](https://www.youtube.com/watch?v=S8hR0CD4Kmc) covers the initial setup, although the full installation may take about an hour. - A project to run. This guide assumes it is located at `~/projects/myapp` inside the VM and includes a `requirements.txt` file. Replace that path with your own. - A code editor on your Mac. VS Code and Cursor support the Remote - SSH extension; any editor can work with a Samba share. ## Step 1: Configure the VM network UTM's Shared Network mode places the VM on a private network that your Mac can access. 1. In UTM, select your Debian VM. Shut it down first if it is running. 2. Open the VM's settings and select **Network**. 3. Set **Network Mode** to **Shared Network**, then save the settings. 4. Start the VM and log in. ### Find the VM's IP address Open a terminal inside the Debian VM and run: ```bash ip a ``` Find a line such as `inet 192.168.64.2/24` under an interface named `enp0s1` or `eth0`. The part before `/` is the VM's IP address. This guide uses `192.168.64.2`. Substitute your VM's address if it differs. ### Test the connection from macOS Open Terminal on your Mac and run: ```bash ping -c 3 192.168.64.2 ``` If you receive replies, your Mac can reach the VM. ## Step 2: Set up the project in Debian ### Install the system packages Run these commands inside the Debian VM: ```bash sudo apt update sudo apt install -y python3-venv python3-pip python3-dev build-essential \ libpq-dev libyaml-dev zlib1g-dev libjpeg-dev libffi-dev git ``` `apt update` refreshes the available package list. `apt install` adds Python tooling, a C compiler, and development headers that common Python packages may need. Check your project's documentation for any additional dependencies. ### Create a virtual environment ```bash cd ~/projects/myapp python3 -m venv ve source ve/bin/activate pip install -r requirements.txt ``` - `cd` moves into the project directory. - `python3 -m venv ve` creates an isolated virtual environment named `ve`. - `source ve/bin/activate` activates it. Your prompt should begin with `(ve)`. Repeat this command in each new terminal session. - `pip install -r requirements.txt` installs the project's Python dependencies. ### Allow connections from your Mac Django rejects requests whose host is not listed in `ALLOWED_HOSTS`. Open your settings file—the exact filename varies by project: ```bash nano localsettings.py ``` For local development, add: ```python ALLOWED_HOSTS = ["*"] ``` Save with `Ctrl+O`, press `Enter`, then exit with `Ctrl+X`. > `"*"` accepts any hostname. It is convenient for local development, but you should use explicit hostnames in production. ### Start the development server Bind Django to all network interfaces so the Mac can reach it: ```bash ./manage.py runserver 0.0.0.0:8000 ``` Django normally listens on `127.0.0.1`, which is accessible only from inside the VM. Binding to `0.0.0.0` makes the server available through the VM's network interfaces. On your Mac, open: ```text http://192.168.64.2:8000 ``` If the app loads, the network and development server are configured correctly. Press `Ctrl+C` in the VM terminal to stop the server. ## Step 3: Connect your editor Choose either Remote - SSH or a Samba share. Remote - SSH gives supported editors a fully remote workspace and terminal. Samba mounts the project as a regular macOS network drive and works with any editor. ### Option 1: Remote - SSH This option works with VS Code, Cursor, and other editors that support an SSH extension. Install and start the SSH server inside Debian: ```bash sudo apt install -y openssh-server sudo systemctl enable --now ssh ``` Confirm that you can log in from macOS. Replace `` with the result of `whoami` inside the VM: ```bash ssh @192.168.64.2 ``` Type `yes` if prompted to trust the host, enter your Debian password, and then run `exit` after the Debian prompt appears. In VS Code or Cursor: 1. Open Extensions with `Cmd+Shift+X` and install **Remote - SSH**. 2. Open the Command Palette with `Cmd+Shift+P` and choose **Remote-SSH: Connect to Host...**. 3. Enter `@192.168.64.2` and provide your password. 4. Choose **File → Open Folder...** and select `/home//projects/myapp`. The editor now reads and writes files directly inside the VM, and its integrated terminal runs Debian commands. If your editor does not support Remote - SSH, use the Samba option instead. ### Option 2: Samba share Install Samba and create a Samba password inside the Debian VM: ```bash sudo apt install -y samba sudo smbpasswd -a "$USER" ``` The Samba password is separate from your Linux login password, although you may choose the same value. Open the Samba configuration: ```bash sudo nano /etc/samba/smb.conf ``` Add this block at the end, replacing the username and project path with your own: ```ini [myapp] path = /home//projects/myapp read only = no browsable = yes valid users = create mask = 0775 directory mask = 0775 ``` - `[myapp]` is the share name used in the network address. - `path` points to the project directory inside Debian. - `valid users` limits access to your Debian user. - The mask settings define permissions for new files and directories. Save with `Ctrl+O`, press `Enter`, and exit with `Ctrl+X`. Then restart Samba and enable it at boot: ```bash sudo systemctl restart smbd sudo systemctl enable smbd ``` On macOS: 1. In Finder, press `Cmd+K` or choose **Go → Connect to Server...**. 2. Enter `smb://192.168.64.2/myapp` and select **Connect**. 3. Choose **Registered User**, enter your Debian username and Samba password, and optionally save them to Keychain. 4. The share mounts at `/Volumes/myapp`. 5. Open `/Volumes/myapp` in your editor. In a macOS file dialog, press `Cmd+Shift+G` to enter the path directly. ## Daily workflow After the initial setup, each development session takes four steps: 1. Start the VM in UTM. 2. Start the development server in the VM: ```bash cd ~/projects/myapp source ve/bin/activate ./manage.py runserver 0.0.0.0:8000 ``` 3. Reconnect your editor: - With Remote - SSH, choose your saved host from **Remote-SSH: Connect to Host...**. - With Samba, press `Cmd+K` in Finder and choose the recent server. 4. Open `http://192.168.64.2:8000` in your browser. Saving a file triggers Django's automatic reloader, so you only need to refresh the browser. The VM's IP address will usually remain the same, but you can confirm it inside Debian with: ```bash ip a | grep "inet 192.168.64" ``` ### [Community Sharing & Templating](https://beebombshell.com/writing/community-templating) - Published: 2025-12-10T00:00:00.000Z - Tags: Work, Product, Architecture, BuildShip ## Overview Community Sharing and Templating was about turning BuildShip from a place where workflows live in isolation into an ecosystem where good work compounds. Users were already building powerful workflows and custom nodes, but there was no structured way to share, document, or reuse them across projects. This project focused on building the foundations for a community marketplace through workflow templates, remixing, documentation, and node contributions, all deeply integrated into the existing builder experience. ## Remix Templates and Workflow Sharing At the core of this system is the idea of remixing workflows. Users can share any workflow using a Remix link directly from the workflow top bar. This generates a public URL that allows others to preview the workflow and clone it into one of their own projects. ![Remix Workflow Preview and Deep Clone Modal](/images/projects/buildship/remix.gif) The remix experience is designed to be frictionless. A user opens the link, selects a target project, and the workflow is deeply cloned without modifying the source. This includes preserving the workflow graph, node configuration, and example values while safely stripping anything project-specific. The Remix Modal handles this entire flow and acts as the primary entry point for sharing workflows publicly. The result is one-click sharing with project-level cloning that feels native to the product rather than bolted on. ## Template Library On top of remixing, I built the Template Library as a dedicated place to discover complete workflows. Templates are presented in a gallery-style interface where users can browse, search, and filter by category such as AI, utility, or database. Each template can be previewed before use and cloned directly into a selected project. ![Template Explorer and Filterable Gallery](/images/projects/buildship/template-explorer.png) The library is integrated with the same project selection and cloning logic used by remix links, ensuring consistency across the sharing experience. This allows new users to get started quickly with production-ready workflow patterns instead of starting from a blank canvas. ## Template Details and Remixing Each template has a detailed view that explains what it does and how to use it. This includes descriptions, README content, and real input-output examples from executions. ![Template Details with Live Execution Examples](/images/projects/buildship/template-details.png) Users can remix templates into their own projects. This required building deep cloning workflows that preserve the workflow graph, node configuration, and example values while removing anything unsafe. I also added internal testing routes to validate templates before they become public. ## Workflow READMEs To make shared workflows understandable, I implemented README support directly within the workflow context. Each workflow can have an associated README page that acts as its documentation. Creating a README is triggered from the workflow top bar using a dedicated hook. Under the hood, this creates a new document in Firestore under the project pages collection, initialized with a structured Markdown template to guide authors. ![Workflow README Embedded in Builder Context](/images/projects/buildship/readme.png) If a workflow is not already organized, the system automatically creates a folder and moves both the workflow and its README into it. This keeps shared templates clean and discoverable. The editor experience is powered by a rich Markdown editor with support for tables, images, code blocks, and interactive Sandpack snippets. Changes are synchronized in real time using a two-way Firestore data flow with debounced persistence to keep edits responsive and safe. ## Community Nodes and Node Library Community sharing extends beyond workflows to the building blocks themselves. The Node Library includes a dedicated Community tab alongside core nodes and personal libraries. This space is designed to surface community-contributed nodes and encourage users to become node makers. ![Node Library with Community Contributions Tab](/images/projects/buildship/community-nodes.png) While the current implementation includes a featured placeholder and call to action, the underlying system supports node submissions, review, and future expansion into a full community catalog. Nodes can be discovered through the same search experience used inside the canvas, keeping discovery close to where users actually build. ## The Developer Experience A large part of this project was about designing for portability and ecosystem growth: - **Frictionless Creation**: Users create workflows and nodes inside their own projects without ecosystem friction. - **Natural Publishing**: Built-in modals make publishing and sharing feel natural and guided. - **Centralized Discovery**: Centralized libraries handle search, filtering, and categorization. - **Seamless Adoption**: Adoption is handled through a consistent project selection flow that automatically manages project limits and resource allocation during cloning. This separation between creation, publishing, discovery, and adoption keeps the system flexible while avoiding tight coupling between community content and core product logic. Community Sharing and Templating laid the groundwork for reuse inside BuildShip. Workflows can now be shared, documented, discovered, and safely cloned. Users can learn from real examples, and the platform has a clear path toward a growing ecosystem of templates and nodes. ### [Human in the Loop](https://beebombshell.com/writing/human-in-loop) - Published: 2025-12-10T00:00:00.000Z - Tags: Work, AI Agents, Slack, BuildShip ## Overview This project focused on enabling Human in the Loop workflows in BuildShip by leveraging the platform’s existing pause and resume execution model. The goal was to let workflows safely wait for human input without breaking automation, consuming credits, or requiring complex workarounds. The result was two production nodes: - **Email Human in the Loop**: Delivers approval requests and input forms directly to user inboxes with dynamic resume links. - **Slack Human in the Loop**: Dispatches interactive message blocks into Slack channels or DMs with live response validation. Both allow workflows to pause, request a decision or structured input from a human, and then resume execution once a response is received. ![Slack Human in the Loop Interactive Workflow](/images/projects/buildship/Slack-hitl.mp4) ## The Problem Many real-world workflows cannot be fully automated: - AI outputs need human review and validation. - Critical operations and financial actions require explicit sign-off. - Contextual and subjective decisions need domain expertise. Before this work, users had to either stop automation entirely or build fragile external approval systems. The requirements were clear: - Allow workflows to pause safely for human input. - Resume cleanly with validated, type-safe data. - Keep the entire authoring experience native to BuildShip. ## Leveraging Pause and Resume BuildShip already supports pausing workflows using an underlying pause and resume mechanism. My work focused on applying this capability to real communication channels and designing a clean developer experience around it. When a Human in the Loop node executes, it calls pause and returns a waiting response. The workflow state is preserved, and a unique resume URL is generated. Execution stops until that URL is invoked. This approach avoids long-running execution, polling, or credit usage while waiting. From the workflow author’s perspective, it feels like a natural pause in the flow. ## Response Models Both Email and Slack nodes support two distinct response models: ![Conditional vs Structured Response Models](/images/projects/buildship/hitl-response.png) - **Conditional responses**: Simple approvals or rejections. Authors can customize button labels, and the node returns a clean boolean result back into the workflow graph. - **Structured responses**: Allow workflow authors to define a JSON Schema describing expected input. Human responses are validated against this schema before the workflow resumes, ensuring downstream nodes receive predictable, typed data. This made it possible to collect real structured input from humans instead of unvalidated free-form text. ## Email Human in the Loop The Email HITL node delivers approval or input requests via email. ![Email Human in the Loop Configuration](/images/projects/buildship/hitl-email.png) When the node runs, it calls an internal workflow responsible for sending the email. That workflow handles authentication, template rendering, and attachments. After triggering the email, the main workflow pauses. Emails include links or buttons wired directly to the resume URL. When a recipient responds, the workflow resumes and processes the result. The implementation supports rich HTML templates, placeholder interpolation, and image handling. Images can be external URLs or files that are automatically converted and uploaded to make them publicly accessible. This allowed email-based approvals without requiring users to build separate email infrastructure. ## Slack Human in the Loop The Slack HITL node integrates with Slack using OAuth and delivers requests directly into channels or direct messages. ![Slack Interactive Message Blocks and Action Handling](/images/projects/buildship/hitl-slack.png) When executed, the node sends a Slack message built from dynamic blocks and then pauses the workflow. Message metadata and resume details are stored in Firestore to preserve state across the pause. When a user interacts with the message, the input handler retrieves the stored context, validates the response, updates the Slack message to mark it as completed, and resumes the workflow. This avoids duplicate responses and gives clear visual feedback inside Slack. ## State Management and Validation Slack-based HITL requires explicit state management. Message timestamps, channel IDs, response schemas, and callback URLs are persisted so the workflow can safely resume later. - **Structured responses** are validated against the original JSON Schema before continuing execution. - **Conditional responses** are passed through directly as boolean decisions. This ensures that human input does not introduce inconsistent or malformed data into downstream workflow nodes. ## Developer Experience A large part of this work focused on DX rather than raw functionality: - Workflow authors can configure HITL nodes without thinking about low-level callbacks or database storage. - Templates support placeholder interpolation and separate states for pending and resolved requests. - Errors are surfaced clearly when workflows are not in a shippable state or when integrations are misconfigured. - The pause itself does not consume runtime credits, making long-running human approvals practical. ### [Workflow READMEs](https://beebombshell.com/writing/readme) - Published: 2024-09-08T00:00:00.000Z - Tags: Work, DevTools, Documentation, BuildShip ## Overview As workflows grow in complexity, understanding them becomes just as important as executing them. Before Workflow READMEs, context lived in people’s heads, Slack threads, or external docs that quickly drifted out of sync. This feature focused on bringing documentation directly into the workflow itself. Workflow READMEs in BuildShip are implemented as first-class pages that live alongside workflows, not as an afterthought or static text field. ## Why READMEs Needed to Live Inside the Product Workflows are often shared, cloned, or revisited weeks later. Without context, it is hard to answer basic questions: - Why does this workflow exist? - What inputs does it expect? - What assumptions does it make? - How should it be customized? External documentation breaks easily, and inline comments are rarely sufficient. READMEs needed to be tightly coupled to the workflow while remaining flexible and expressive. ## Creating a README READMEs are created directly from the workflow top bar. When a user selects **Create Read Me**, the feature uses a dedicated hook to trigger page creation. Under the hood, this calls a shared atom responsible for creating new pages in Firestore under the project’s pages collection. Each README starts from a predefined Markdown template. This gives users a structured starting point instead of a blank editor, encouraging better documentation by default. To keep projects organized, the system ensures that READMEs and workflows live together. If a workflow is not already in a folder, a new folder is created automatically and both the workflow and its README are moved into it. This small detail prevented a lot of long-term clutter. ## Editing Experience The README editor is built using a rich WYSIWYG Markdown editor (pronounced *"wiz-ee-wig"*, standing for "What You See Is What You Get"), rather than a raw text area. ![Rich Markdown Editor with Sandpack Integration](/images/projects/buildship/readme-mdx.png) Users can write standard Markdown while also having access to richer features such as tables, images, and code blocks. Image uploads are handled through the BuildShip API, so assets remain accessible and stable. For more advanced use cases, the editor supports Sandpack, allowing interactive code snippets to live directly inside the README. This made READMEs useful not just for description, but for interactive teaching and onboarding. All editing logic is centralized in a dedicated `PageEditor` component, keeping the feature modular and extensible. ## Real-Time Collaboration and Persistence READMEs are backed by Firestore and use real-time synchronization. The `usePage` hook handles **two-way data flow**: - It listens for updates from Firestore so multiple users can see changes live. - It persists local edits back to the database with debounced persistence to avoid excessive writes. This allowed READMEs to behave more like collaborative documents than static files, without exposing that complexity to users. ## Routing and Navigation Each README is accessed through a dedicated page route in the v2 routing system. This keeps documentation navigable, linkable, and shareable, while still being clearly associated with a specific workflow. READMEs are not hidden modals or side panels—they are full pages that can grow as workflows grow. Workflow READMEs unlocked several practical benefits: - **Clarity & Reuse**: Shared workflows became easier to understand and reuse across teams. - **Comprehensive Guidance**: Templates could explain setup and customization clearly with interactive snippets. - **Contextual Decisions**: Teams could document decisions close to execution logic. - **Frictionless Onboarding**: Onboarding new users and teammates became significantly easier. Most importantly, documentation stopped being optional. By making it easy and integrated, it became an organic part of the workflow authoring process. ### [Object Detection with BuildShip's Google Vision API Template](https://beebombshell.com/writing/google-vision-api) - Published: 2024-05-20T00:00:00.000Z - Tags: Work, AI, Pipelines, BuildShip ## Bringing Computer Vision to Serverless Workflows Computer vision has rapidly become a core capability for modern software, enabling everything from automated inventory tracking and quality inspection to intelligent media moderation. However, traditionally integrating vision models into production applications required substantial infrastructure overhead: provisioning GPU or containerized backend servers, configuring Google Cloud service accounts and SDKs, parsing multi-part payloads, and calculating bounding box coordinate transforms. While building templates and nodes at BuildShip, I wanted to bridge this gap. The goal was to provide an end-to-end, production-ready template that packages Google Cloud Vision's object localization into a visual, low-code workflow that any developer can remix and customize in minutes. ## Architecture of the Google Vision Workflow The template exposes an HTTP endpoint that ingests an image URL, analyzes its contents via Google Vision API, detects objects, and returns both structured JSON metadata and an annotated image with colored bounding boxes and labels. Here is how the end-to-end pipeline operates: 1. **HTTP Trigger (`/detectobjects`)**: The workflow starts with an incoming GET request that takes a query parameter, `imageURL`, pointing to the target image file. 2. **Input Validation**: The URL is validated to ensure it points to a reachable, supported image format (JPEG, PNG, WebP). 3. **Google Cloud Vision Node**: The image URL is passed to BuildShip's Google Vision localization node. Under the hood, this makes an authenticated request to the Google Vision API, executing an `OBJECT_LOCALIZATION` feature query. 4. **Bounding Box Calculation**: Google Vision returns a list of detected objects, each with a localized name, confidence score (`0.0` to `1.0`), and normalized bounding polygon vertices. 5. **Visual Annotation (Canvas / Headless Renderer)**: A downstream node computes the pixel coordinates from the normalized vertices and draws bounding boxes with category tags directly over the original image. 6. **API Response**: The workflow responds with a clean JSON payload containing the detected entities along with the newly rendered annotated image asset. ![Object Detection Workflow Architecture in BuildShip](/images/blog/vision-workflow.jpeg) ## Real-World Use Cases Integrating object detection as an API endpoint unlocks immediate automation opportunities across industries: - **E-Commerce & Inventory Management**: Automatically categorize items from warehouse cameras or seller product uploads, verifying that required items are present before listing. - **Smart Asset Tagging & DAM**: Ingest thousands of marketing assets, automatically tag visible items (e.g., laptops, clothing, vehicles), and index them for rapid internal search. - **Security & Workplace Safety**: Monitor facility imagery for required safety equipment like helmets and vests, triggering instant notifications when safety compliance standards are breached. - **Social & UGC Moderation**: Detect prohibited items or inappropriate objects in user uploads before they are published to public feeds. ## Handling Coordinate Normalization A common gotcha when working with Google Vision API is handling coordinate geometry. Rather than returning absolute pixel values, Google Vision returns normalized vertices where $x$ and $y$ are floats between `0.0` and `1.0`, representing the proportion of the image width and height. By abstracting this coordinate transformation inside the workflow node, consumers of the template do not have to write custom canvas drawing logic. They simply pass an image URL and receive the annotated result ready for downstream consumers. ## Extensibility & Composable Pipelines The true power of this template lies in its composability. Because BuildShip connects visual triggers and nodes seamlessly, you can branch the workflow to: - Store detected object tags directly in **Firestore**, **Supabase**, or **Postgres**. - Trigger alerts in **Slack** or **Discord** if a specific item or anomaly is identified. - Feed the detected labels into **OpenAI** or **Claude** to generate an automated descriptive summary of the scene. You can inspect the full workflow and try out the template directly on [BuildShip](https://buildship.com), or check out the [original post on Medium](https://medium.com/@beebombshell). ### [Framer CMS Data Sync Plugin](https://beebombshell.com/writing/framer-cms-plugin) - Published: 2025-12-26T00:00:00.000Z - Tags: Framer, CMS, Plugins, Data Sync ## Keeping Framer CMS in Sync with Real Products I built CMS Data Sync while working on the BuildShip Integrations website, a Framer-powered site with over 500 pages that needed to stay in sync with a fast-moving product. Framer is exceptionally good at what it sets out to do. It makes layout, interaction, and visual polish feel almost effortless. But as the site grew and the product evolved, a quiet tension started to show up: the CMS was becoming a bottleneck. Framer does not support API calls or automations by design. Content is expected to be edited manually. For small sites, that is perfectly reasonable. For a product-driven website, it slowly becomes brittle. Pages fall out of date. Schemas change. The website starts lagging behind the system it is supposed to represent. I wanted Framer to stay what it does best: a UI layer. I needed the data to come from somewhere else. You can find the plugin on the [Framer Marketplace](https://www.framer.com/marketplace/plugins/cms-data-sync/). ## Finding the Right Extension Point Plugins turned out to be the only place where this was possible. They are the one part of Framer that can reach outside, fetch data, and write back into the CMS. Framer already has plugins for specific tools like Google Sheets or Airtable. They work well for narrow use cases, but they lock you into a single source. What I needed was something more flexible: something that could connect to anything, as long as it could return structured data. That is where BuildShip fit naturally. ![Connecting BuildShip Workflow Endpoint to Framer CMS](/images/projects/buildship/framer-cms-2.jpg) ## What CMS Data Sync Enables CMS Data Sync connects Framer CMS to BuildShip workflows and treats external systems as the source of truth: - **Connect**: Hook up any BuildShip workflow endpoint that outputs structured JSON. - **Preview**: Inspect incoming records and verify schemas in real time. - **Map Fields**: Intuitively map external JSON keys to Framer CMS fields and collection types. - **Stable Identifiers**: Select an identifier field so repeated syncs update existing items instead of creating duplicates. The CMS stops being something you constantly edit and starts behaving more like a projection of your product state. ## A Tool People Actually Use Today, CMS Data Sync has more than 1,300 active users. Many of them are using Framer beyond simple marketing pages—building documentation, integration directories, and product surfaces that change frequently. The plugin is intentionally designed for developers, but without feeling hostile to designers. The UI explains what is happening, surfaces good defaults, and avoids destructive actions. Automation should feel calm, not risky. ![Automated Field Mapping and Controlled CMS Data Sync](/images/projects/buildship/framer-cms-3.jpg) ## Why This Approach Matters Rather than adding yet another point integration, CMS Data Sync takes a more general approach. By sitting on top of BuildShip, it can connect to databases, internal services, third-party APIs, or computed workflows without changing how Framer is used. For teams that want Framer’s speed and polish without giving up control over their data pipelines, this ends up being a surprisingly effective balance. You can install the plugin from the [Framer Marketplace](https://www.framer.com/marketplace/plugins/cms-data-sync/), and there is a detailed setup guide available in the [BuildShip documentation](https://docs.buildship.com/tutorials/framer-cms). ### [Object Detection with BuildShip's Google Vision API Template](https://beebombshell.com/writing/google-vision) - Published: 2024-05-20T00:00:00.000Z - Tags: Vision AI, Object Detection, Workflows, Tutorial ## Bringing Computer Vision to Serverless Workflows Computer vision has rapidly become a core capability for modern software, enabling everything from automated inventory tracking and quality inspection to intelligent media moderation. However, traditionally integrating vision models into production applications required substantial infrastructure overhead: provisioning GPU or containerized backend servers, configuring Google Cloud service accounts and SDKs, parsing multi-part payloads, and calculating bounding box coordinate transforms. While building templates and nodes at BuildShip, I wanted to bridge this gap. The goal was to provide an end-to-end, production-ready template that packages Google Cloud Vision's object localization into a visual, low-code workflow that any developer can remix and customize in minutes. ## Architecture of the Google Vision Workflow The template exposes an HTTP endpoint that ingests an image URL, analyzes its contents via Google Vision API, detects objects, and returns both structured JSON metadata and an annotated image with colored bounding boxes and labels. Here is how the end-to-end pipeline operates: 1. **HTTP Trigger (`/detectobjects`)**: The workflow starts with an incoming GET request that takes a query parameter, `imageURL`, pointing to the target image file. 2. **Input Validation**: The URL is validated to ensure it points to a reachable, supported image format (JPEG, PNG, WebP). 3. **Google Cloud Vision Node**: The image URL is passed to BuildShip's Google Vision localization node. Under the hood, this makes an authenticated request to the Google Vision API, executing an `OBJECT_LOCALIZATION` feature query. 4. **Bounding Box Calculation**: Google Vision returns a list of detected objects, each with a localized name, confidence score (`0.0` to `1.0`), and normalized bounding polygon vertices. 5. **Visual Annotation (Canvas / Headless Renderer)**: A downstream node computes the pixel coordinates from the normalized vertices and draws bounding boxes with category tags directly over the original image. 6. **API Response**: The workflow responds with a clean JSON payload containing the detected entities along with the newly rendered annotated image asset. ![Object Detection Workflow Architecture in BuildShip](/images/blog/vision-workflow.jpeg) ## Real-World Use Cases Integrating object detection as an API endpoint unlocks immediate automation opportunities across industries: - **E-Commerce & Inventory Management**: Automatically categorize items from warehouse cameras or seller product uploads, verifying that required items are present before listing. - **Smart Asset Tagging & DAM**: Ingest thousands of marketing assets, automatically tag visible items (e.g., laptops, clothing, vehicles), and index them for rapid internal search. - **Security & Workplace Safety**: Monitor facility imagery for required safety equipment like helmets and vests, triggering instant notifications when safety compliance standards are breached. - **Social & UGC Moderation**: Detect prohibited items or inappropriate objects in user uploads before they are published to public feeds. ## Handling Coordinate Normalization A common gotcha when working with Google Vision API is handling coordinate geometry. Rather than returning absolute pixel values, Google Vision returns normalized vertices where $x$ and $y$ are floats between `0.0` and `1.0`, representing the proportion of the image width and height. By abstracting this coordinate transformation inside the workflow node, consumers of the template do not have to write custom canvas drawing logic. They simply pass an image URL and receive the annotated result ready for downstream consumers. ## Extensibility & Composable Pipelines The true power of this template lies in its composability. Because BuildShip connects visual triggers and nodes seamlessly, you can branch the workflow to: - Store detected object tags directly in **Firestore**, **Supabase**, or **Postgres**. - Trigger alerts in **Slack** or **Discord** if a specific item or anomaly is identified. - Feed the detected labels into **OpenAI** or **Claude** to generate an automated descriptive summary of the scene. You can inspect the full workflow and try out the template directly on [BuildShip](https://buildship.com), or check out the [original post on Medium](https://medium.com/@beebombshell). ### [How to Create a Telegram Bot with No Code — using BuildShip (2024)](https://beebombshell.com/writing/telegram-bot) - Published: 2024-04-12T00:00:00.000Z - Tags: Telegram, No-Code, Automation, Bot ## Why Telegram Bots Are the Ultimate Conversational Interface Telegram has one of the cleanest and most developer-friendly bot platforms available today. With hundreds of millions of active users and rich client capabilities, bots on Telegram can handle everything from automated community moderation and customer support to personalized AI assistants and interactive games. Traditionally, deploying a custom Telegram bot required configuring persistent servers or serverless webhook endpoints, managing SSL certificates, registering webhook URLs through Telegram's HTTP API, and manually handling JSON request parsing. With BuildShip, you can build and launch a fully featured, AI-powered Telegram bot in minutes completely visually, without managing servers or writing boilerplate glue code. ## Step 1: Create Your Bot with BotFather Every Telegram bot begins with **@BotFather**, Telegram's official bot creation tool: 1. Open Telegram and search for `@BotFather` (ensure it has the verified blue badge). 2. Send the `/newbot` command. 3. Choose a display name for your bot (e.g., `My Assistant Bot`). 4. Choose a unique username that ends in `bot` (e.g., `my_assistant_robot`). 5. BotFather will provide you with an **HTTP API Token** (format: `123456789:ABCdefGhIJKlmNoPQRsTUVwxyZ`). Copy this token and store it securely—this key authenticates all requests to Telegram on behalf of your bot. ## Step 2: Configure the Telegram Bot Trigger in BuildShip Now that you have your Bot API Token, head over to BuildShip: 1. Create a new workflow or remix the **Telegram Bot Template**. 2. Select the **Telegram Bot Trigger** as the entry point of your workflow. 3. Paste your Bot API Token into the trigger configuration. 4. When you ship or test the workflow, BuildShip automatically calls Telegram's `setWebhook` endpoint behind the scenes, routing all incoming user messages directly to your workflow execution environment. ![Telegram Chatbot Trigger Configuration in BuildShip](/images/blog/telegram-trigger.jpeg) Whenever a user sends a message, your workflow receives an event payload containing: - `chatId`: The unique identifier for the user or group conversation. - `message`: The raw text of the incoming message. - `from`: Metadata about the sender (first name, username, user ID). ## Step 3: Injecting AI Intelligence with OpenAI A standard chatbot that only responds with rigid regex rules feels robotic. By chaining an **OpenAI GPT** node, your bot gains natural language reasoning: 1. Add the **OpenAI Text Generator** node right after the Telegram trigger. 2. Connect the incoming message text to the `prompt` input. 3. Provide a custom `systemPrompt` defining your bot's behavior, tone, and constraints. Because BuildShip supports dynamic expressions, you can also inject the user's name (`{{trigger.from.first_name}}`) into the prompt for a personalized greeting. ## Step 4: Dispatching Responses Back to Telegram The final piece of the pipeline is sending the generated answer back to the user: 1. Add the **Send Telegram Message** node to the workflow. 2. Pass the `chatId` from the trigger into the `chat_id` field. 3. Pass the generated text output from the OpenAI node into the `text` field. 4. Set parse mode to `Markdown` or `HTML` if you want rich formatting like bold text, bullet points, or inline links. ![Telegram Send Message Node Dispatching Responses](/images/blog/sending-messages.jpeg) Click **Ship**, and your bot is immediately live in Telegram! Open your bot's conversation in Telegram, send a message or `/start`, and watch the bot respond in real time. ## Expanding Your Bot: Memory, Tools, and Database Sync Because BuildShip is an extensible backend builder, you aren't restricted to basic text replies: - **Conversational Memory**: Connect a **Firestore** or **Supabase** node to store conversation history by `chatId`, allowing the bot to remember context across multiple messages. - **Audio & Media**: Use Telegram's audio and photo action nodes to accept voice notes from users, transcribe them using **Whisper**, and send back audio responses. - **Webhook Integrations**: Trigger backend actions like creating a Linear issue, submitting a form, or notifying your team in Slack based on user commands. [**Read the original tutorial on Medium →**](https://medium.com/@beebombshell/how-to-create-a-telegram-bot-with-no-code-using-buildship-workflow-builder-2024-03207f2b1d68) ### [How to Generate SEO-Friendly Technical Blogs from YouTube Videos](https://beebombshell.com/writing/seo-technical-blogs) - Published: 2024-02-10T00:00:00.000Z - Tags: SEO, AI, YouTube, Content Engineering ## The Content Bottleneck: Great Videos, Lost Discoverability Developers, tech educators, and product teams spend countless hours creating informative YouTube tutorials, tech talks, and conference presentations. While video is fantastic for deep visual learning, it has a significant limitation: search engines and developers looking for quick answers primarily consume and index written text. When a developer runs into a cryptic terminal error or wants to learn an API, they search on Google or developer forums. If your insight is buried inside minute 14 of a video, it is practically invisible to search queries. Transcribing and writing full technical blog posts manually can take 4 to 8 hours per video. In this post, I break down an automated pipeline built on BuildShip that converts YouTube videos into structured, SEO-optimized technical blog posts in seconds. ## The End-to-End Pipeline Architecture Transforming spoken video dialogue into a readable, high-ranking technical post requires more than just dumping an audio transcript into a basic summarizer. The pipeline consists of five key stages: 1. **Trigger & Video Ingestion**: A workflow trigger accepts a YouTube video URL or monitors a YouTube channel for newly published videos using the YouTube Trigger node. 2. **Transcript Extraction**: Using the YouTube Caption Extractor node (or Whisper API for uncaptioned videos), the workflow fetches the raw timestamped subtitles. 3. **Punctuation & Noise Reduction**: Raw auto-generated captions often lack punctuation, include filler words ("um", "like", "you know"), and contain spoken artifacts that need cleaning. 4. **Structured LLM Synthesizer**: An OpenAI node with a specialized system prompt analyzes the cleaned transcript, identifies the core technical concepts, preserves code blocks, and outlines the tutorial. 5. **SEO & Markdown Formatting**: The output is structured with clear `H2` and `H3` headings, a concise summary, key takeaways, and keyword-rich metadata ready for publication. ![AI Pipeline for Generating Technical Blogs from YouTube Videos](/images/blog/seo-workflow.jpeg) ## Prompt Engineering for Technical Precision Generic summarization prompts tend to flatten code tutorials into vague summaries. For technical blogs, accuracy, code clarity, and structural hierarchy are paramount: - Constrain the model to generate explicit code blocks with appropriate syntax highlighting tags. - Instruct the prompt to identify prerequisite CLI tools, package versions, and environment configurations. - Require high-density explanations over generic conversational filler. By constraining the model to output clean Markdown with explicit code fences, the generated output can be published directly to CMS platforms like **Framer**, **Dev.to**, **Hashnode**, or **Ghost**. ## Optimizing for Technical Search Intent To ensure the resulting article ranks well and delivers genuine value to readers, the workflow incorporates specific SEO best practices: - **Targeted Long-Tail Headings**: Instead of generic headings like "Next Step", the model generates descriptive titles matching search queries (e.g., `## Configuring Environment Variables in Docker`). - **Skimmable Code Snippets**: Developers skim tutorials for code blocks first. Every command and configuration snippet is formatted with proper language tags. - **Fast Executive Summary & TL;DR**: A brief introductory overview that helps both search engine crawlers and busy engineers understand the core solution immediately. - **Structured Meta Description**: Automated generation of a 150-character meta description optimized for Google search snippets. ![Postman API Testing and Verification Workflow](/images/blog/postman.jpeg) ## Scaling Content Distribution By connecting the output of this workflow to automated distribution channels, teams can turn every video into a multi-platform content engine: - Syncing articles directly to a **Framer CMS** collection or Headless CMS. - Cross-posting draft articles to **Dev.to** and **Hashnode** via their respective APIs. - Pushing social media thread drafts to Slack for immediate editorial review. Automating the conversion of rich video media into indexable, high-quality technical writing bridges the gap between great content creation and lasting organic discovery. ## Contact and profiles - GitHub: https://github.com/BeeBombshell - X: https://x.com/Bee_Bombshell - LinkedIn: https://www.linkedin.com/in/beebombshell