Fling is Claude Code's missing Publish button

My cofounder, Jason, and I built Fling over about 2 months on the hunch that giving Claude Code an easy-to-use “Publish” button would unlock it for a larger group of users. This is how we built it, and what we learned.

Try Fling

What is Fling?

Fling is a tool for your coding agent that gives it the power to quickly publish software to the internet.

Fling lets users build and deploy personal tools through conversation with Claude. You describe what you want, Claude writes the code, and Fling handles everything else; bundling, deployment, databases, cron jobs, storage, secrets, and routing. No infrastructure knowledge required.

This is why we say Fling is Claude Code’s missing Publish button.

Thesis

We believe that the number of people using coding agents like Claude Code “directly” will explode in the months and years to come, because:

While they still feel scary to use, they are being packaged in more friendly and safer ways, such as Claude Desktop, and this trend will continue.
People are catching on to how powerful they are, which will convince more people to give them a try.
In contrast to vibe-coding platforms like Lovable, first-party coding agents are still heavily subsidized by model companies, which means one gets a lot more usage out of them for the same price.

Most of the software built by this new mass of users will be what we call “Small Software”: small tools that solve a specific problem in the user’s life, work, hobby, or social circle. Those might be very short-lived, like the organization of a hackathon, or just for fun.

One thing holding this back is that these coding agents are missing a “Publish” button that puts the software on the internet, either to share it with others or for the builder to use themselves while on the go.

We wanted to build such a Publish button and find out how useful it really is.

Results

We built Fling as an agent-first app-hosting platform on top of Cloudflare. That technology choice has paid off in both simplicity and cost, and its limitations have not been serious problems.

What Fling is:

A deployment platform for “Small Software”.
The interface to that is a CLI, built to be used by the coding agent.
A skill for the coding agent that tells it what the platform’s APIs are, and how to use the CLI.

In a way, Fling is defined by what it is not:

It doesn’t bundle or run the model/agent. Instead, it’s a tool for the agent you’re already using, on your machine, or wherever you like running it.
It doesn’t require you to learn how to use another system. Fling is built for your agent to use, and if you want something accomplished, you just talk to your agent, like you’ve already been doing.
It doesn’t hold your projects’ source code or do version control. Instead, your project is just a directory on your computer, like any other project. Source control is up to you.

This avoids 90% of the complexity of vibe-coding platforms like Lovable:

We don’t have to run sandboxes.
There’s no graphical UI.
We don’t need to implement or integrate with a coding agent loop.
We don’t have to worry about billing for tokens or how to recuperate free use.
Source control is not our problem.

How Fling is being used:

Fling has significantly reduced the activation energy for publishing software. This, in turn, has encouraged people to start making software for all sorts of small but meaningful use cases, for example:

Support is building internal tools.
Solutions is shipping small but important apps to customers, for example, a pricing calculator for a hardware company.
Glide team members have been building software for work and personal use. Stephen created “Fling Build” (see below), which Katie is using to build quick prototypes for prospective customers.
A Glide Expert built a mini-SaaS: https://zipzign.com/
The Fling homepage is, naturally, a fling.
And of course, people are building silly games.

On top of all that, the architectural lessons we’ve learned from Fling have turned out to be invaluable for Glide’s next-generation product, but that’s something we can’t cover here yet.

Example: A typical Fling session

The way I like to start a new Fling is to create an empty directory and run npx flingit. If you’d like to follow along, you can do the same:

❯ npx flingit
│
◆  Select a Fling project to open:
│  ● Create new project
│  ○ ~/Work/fling-projects/fake-discord
│  ○ Cancel
◆  Where would you like to create a new Fling project?
│  ○ Start in ~/flings/my-first-fling
│  ● Start in current directory (~/Work/fling-projects/flingle)
│  ○ Enter a path
│  ○ Cancel
└

Creating your Fling project at ~/Work/fling-projects/flingle...

Initializing Fling project...

Opening Claude Code in ~/Work/fling-projects/flingle...

Next time, you can run Claude Code directly in that directory with `claude`.
Claude Code knows how to use fling. Just tell it what you want to build.

Fling has initialized the project and will now start Claude Code. It also tells me the only thing I have to do from now on is to run Claude Code in this directory, like I normally would.

 ▐▛███▜▌   Claude Code v2.1.38
▝▜█████▛▘  Opus 4.6 · Claude Max
  ▘▘ ▝▝    ~/Work/fling-projects/flingle

─────────────────────────────────────────────────────────────────────────────
❯ Let's make a simple Wordle-like game, but instead of having 6 guesses, you
  can have as many as you want, and what counts is how quickly you guess the
  word. Time starts at the first keystroke. There should be a different word
  every day, and the fastest time for the current day should be recorded.
─────────────────────────────────────────────────────────────────────────────
  ⏵⏵ accept edits on (shift+tab to cycle)

⏺ Let me start by understanding the Fling platform and what tools are available.

⏺ Skill(fling)
  ⎿  Successfully loaded skill

Claude Code understands that this is a Fling project, and so it reads the flingskill that’s been copied here when the project was initialized. Now it builds the game, and when it’s done, it does a bit of basic testing. This is just Claude Code doing its stuff:

⏺ Let me look at the existing project structure first.

⏺ Read 5 files (ctrl+o to expand)

⏺ Now I have a clear picture. Let me build the Wordle speed game. I'll create
  the word list, backend API, and frontend all in parallel.

[lots of Claude Coding elided here]

⏺ Now let me start the dev server to test it.

⏺ Bash(npm start 2>&1)
  ⎿  Running in the background (↓ to manage)
  ⎿  (timeout 15s)

⏺ Read 1 file (ctrl+o to expand)

⏺ Server is running. Let me test the API and the game.

⏺ Bash(curl -s http://localhost:3210/api/best-time | python3 -m json.tool)
  ⎿  {
         "date": "2026-04-14",
         "bestTime": null,
     … +2 lines (ctrl+o to expand)

⏺ Bash(curl -s -X POST http://localhost:3210/api/guess -H 'Content-Type: application/json' -d '{"guess":"crane"}' | python3 -m json.tool)
  ⎿  {
         "result": [
             {
     … +23 lines (ctrl+o to expand)

⏺ Both endpoints work. Let me also test submitting a non-word and verify the
  validation works.

⏺ Bash(curl -s -X POST http://localhost:3210/api/guess -H 'Content-Type: application/json' -d '{"guess":"zzzzz"}' | python3 -m json.tool)
  ⎿  {
         "error": "Not in word list"
     }

⏺ Everything is working. The game is running at http://localhost:5173. Here's
  what I built:

  Flingle - A speed Wordle game:

  - Unlimited guesses - no 6-guess limit, just solve it as fast as you can
  - Timer starts on first keystroke - shows elapsed time in seconds with
    centisecond precision
  - Daily word - deterministically picks a word from a ~530-word list based
    on the date (UTC)
  - Best time tracking - records the fastest solve time for each day in the
    database
  - Full Wordle mechanics - green (correct), yellow (present), gray (absent)
    with proper keyboard coloring
  - Works on mobile - on-screen keyboard with responsive layout
  - Dark mode - automatically adapts to system preference

  Want to try it locally, or shall I deploy it?

It tells me that the game is running locally, so I open it and play with it. I have a couple of refinements that I’ll make Claude Code implement, but I’ll spare you those parts. Once I’m happy with the game and I want to share it with my friends and the wider world, I just tell Claude Code to “fling it”:

─────────────────────────────────────────────────────────────────────────────
❯ Fling it!
─────────────────────────────────────────────────────────────────────────────

⏺ Bash(npx fling it 2>&1)
  ⎿  Building frontend with Vite...

     Frontend build complete.
     … +17 lines (ctrl+o to expand)
  ⎿  (timeout 2m)

⏺ It's live at https://proj-5527xd.flingit.run!

  Want me to set a custom slug for it? Something like flingle would give you
  https://flingle.flingit.run.

─────────────────────────────────────────────────────────────────────────────
❯ Great idea!
─────────────────────────────────────────────────────────────────────────────

⏺ Bash(npx fling --cli project slug:set flingle 2>&1)
  ⎿  Current slug: proj-5527xd
     Current URL:  https://proj-5527xd.flingit.run
     … +9 lines (ctrl+o to expand)

⏺ Done! Your game is now at https://flingle.flingit.run

Done! You can play it right now at https://flingle.flingit.run. Note that I didn’t have to set up any services, provision infrastructure, or even make tech stack decisions.

If you’re doing this for the first time, at the point when you publish, Claude Code will ask you to sign up (it’s free!), which you’ll only have to do once.

Process: How we assembled Fling’s Architecture

Fling consists of three essential components, plus a skill that teaches the agent how to use them.

If you want much more information, read this architecture deep dive.

These are the three pieces:

CLI — Command Line: The tool for the coding agent. Scaffolds projects, runs local dev, manages secrets, bundles code, and deploys to the platform.
Runtime — Dual Runtime:Same API, two implementations. Users write code once — it runs on Node.js locally and on Cloudflare Workers in production.
Platform — Cloudflare Workers: Seven workers running on the edge. Handle auth, deployments, request routing, cron dispatch, email, and plugin integrations.

The Fling CLI

The Fling command line interface is built to be used primarily by the agent, in a way that it can make quick progress even if things don’t go ideally. That has consequences both for the happy-path as well as for failures.

The whole functionality of the CLI must be discoverable through the CLI itself. Every command must have an explanation and examples.
The names and syntax of commands should be what the agent expects it to be, without even looking at documentation or examples. If we see the agent using the CLI incorrectly, we try to fix it by making the CLI work the way the agent expects it to.
Similarly, CLI commands should do what the agent expects them to, no more, no less, or at least report if they did so. It also follows that Fling should avoid implicit “magic” because that confuses the agent more than it helps.
It must never fail silently. Failures (even if the entire operation succeeded) must always be reported with enough context for the agent to figure out what the problem is.
When failures happen, we try to suggest next steps for making progress.
The CLI does sanity and update checks when it’s run, and reports if there are problems or outstanding updates and how to address them. This contradicts the “don’t do anything unexpected” principle, but the CLI doesn’t mutate anything in those cases, and it’s explicit about what’s happening. In practice, this works very well for keeping the CLI up to date.

The structure of Fling projects

Every Fling project is initially populated from a template, and it looks very much like a simple web app with a React frontend and an Express/Hono backend. The only details that make it a Fling project are:

It depends on the flingit NPM package, which gives it the CLI and a simple “runtime API” for the project’s backend to interface with Fling’s functionality.
It includes the fling skill, which teaches the agent how to use the CLI and the runtime API.

package.json         # NPM package, with `flingit` dependency
src/
  worker/
    index.ts         # Backend API entry point
  react-app/
    main.tsx         # React entry point
    App.tsx          # Main React component
    App.css          # Component styles
    index.css        # Global styles
public/              # Static assets (served by Vite)
index.html           # Entry HTML
vite.config.ts       # Vite configuration
.fling/
  secrets            # Local secrets (gitignored)
  data/              # Local database & storage (gitignored)
    local.db         # SQLite database
    storage/         # Local blog storage
.claude/
  skills/
    fling/
      SKILL.md       # The Fling skill
      references/    # more in-depth Fling docs

The runtime API

The flingitpackage exposes a bunch of simple APIs for the backend to serve HTTP, access secrets, talk to the database and storage, declare cron jobs, send/receive email, and act as Slack/Discord bots. These APIs are designed not to surprise the agent. Here’s a simple example with a cron job that talks to the database:

import { cron, db } from "flingit";

// Runs at 3 AM daily
cron("daily-cleanup", "0 3 * * *", async () => {
  const stmt = "DELETE FROM old_logs WHERE created_at < ?";
  const cutoff = Date.now() - 86400000;
  await db.prepare(stmt).bind(cutoff).run();
});

Note that we’re using the actual Cron syntax here. If we had designed this API for humans, we would have been very tempted to provide a more human-readable syntax here, but for coding agents, that’s completely unnecessary: they are native Cron speakers.

The runtime is compiled TypeScript code that is bundled with the app’s backend when the fling is deployed. But the runtime code that works in the deployed platform is not what works when running the app locally. To service that need, we actually have a second, independent implementation of the runtime that’s used in that case.

Some things are very similar, such as the web server. Instead of using the deployment database, it uses SQLite with the local database .fling/data/local.db. Blob storage is implemented by just storing files in .fling/data/storage. Cron jobs are started by a simple scheduler that runs in the process. Inbound email is “simulated” by calling the CLI, which triggers an internal endpoint in the locally running backend. Outbound email just prints a log entry.

All of that combines to give quite a faithful experience to the deployed app and makes debugging easy.

The platform: Cloudflare Workers

When we planned the deployment platform, we put a bunch of constraints on its architecture, dictated by the main use cases we foresaw:

We needed infrastructure that allows us to host low-usage software cheaply, and no-usage software for free. Optimizing for high-usage software was not a priority. The main drivers of cost are the compute for backend code, and the database.
We’re not deploying a single app, but potentially thousands or millions, and we wanted those to not share resources with each other or with the platform, i.e., each app gets its own database, storage bucket, etc. That avoids noisy-neighbor issues, some security problems, and makes it less likely that a buggy change in the platform will impact the apps running on it.
It must be easy to monitor and limit each individual project’s usage/costs.
We wanted to use a single provider, out of our past bad experiences with building platforms that mix and match them.

What we chose

We did not do a deep, thorough survey of the options available because one jumped out very early as a strong contender that offers everything under one umbrella: Cloudflare.

Cloudflare’s backend compute (Workers), SQL database (D1), and storage (R2) are all very cheap at low usage.
They have “Workers for Platforms”, which allows deploying potentially millions of independent, “sandboxed” apps behind a single domain.
Usage monitoring/limiting is fairly straightforward.

The centerpiece of Cloudflare’s architecture is “workers”. They are essentially lightweight serverless functions that run JavaScript or WASM, have fairly constrained resource limits, but spin up very quickly. With “Workers for Platforms”, it’s possible to programmatically deploy workers, and to give each of them a custom hostname in a single domain, identified by a “slug” like my-stuff.flingit.run.

The way these hostnames work is that all requests to that domain flingit.runare processed by a so-called “dispatch worker”, which has to identify, via the hostname in this case, which “user worker” that request should be routed to. It does that with a lookup in Fling’s platform database, and then it hands the request off to that user worker.

                                 Internet traffic                                                                 
                                                                                                                  
                                         │                     ┌─────────────────────────────────────────────────┐
                                         ▼                     │Dispatch namespace                               │
                             ┌───────────────────────┐         │                              ┌───────────────┐  │
                        ┌────│    Dispatch worker    │────┐    │                          ┌──▶│     DB 1      │  │
                        │    └───────────────────────┘    │    │      ┌───────────────┐   │   └───────────────┘  │
                        │                                 │    │  ┌──▶│ User Worker 1 │───┤                      │
                        │    ┌───────────────────────┐    │    │  │   └───────────────┘   │   ┌───────────────┐  │
                        ├────│    Discord worker     │────┤    │  │                       └──▶│   Storage 1   │  │
┌──────────────────┐    │    └───────────────────────┘    │    │  │                           └───────────────┘  │
│                  │    │                                 │    │  │                                              │
│                  │    │    ┌───────────────────────┐    │    │  │                           ┌───────────────┐  │
│   Platform DB    │◀───┼────│     Slack worker      │────┼───▶├──┤                       ┌──▶│     DB 2      │  │
│                  │    │    └───────────────────────┘    │    │  │   ┌───────────────┐   │   └───────────────┘  │
│                  │    │                                 │    │  └──▶│ User Worker 2 │───┤                      │
└──────────────────┘    │    ┌───────────────────────┐    │    │      └───────────────┘   │   ┌───────────────┐  │
                        ├────│ Inbound email worker  │────┤    │                          └──▶│   Storage 2   │  │
                        │    └───────────────────────┘    │    │                              └───────────────┘  │
                        │                                 │    │                        .                        │
                        │    ┌───────────────────────┐    │    │                        .                        │
                        └────│      API worker       │────┘    │                        .                        │
                             └───────────────────────┘         │                                                 │
                                         ▲                     └─────────────────────────────────────────────────┘
                                         │                                                                        
                                                                                                                  
                                    Fling CLI

Fling's Cloudflare Workers architecture

How the platform talks to the workers “privately”

Some features of Fling require that the platform can send messages to a user worker privately, that is, without hitting an HTTP route that could also be reached from the outside. We solved this in a straightforward way that is enabled by how Workers for Platforms work:

The user workers’ runtime defines several internal routes that all start with double underscores.
The dispatch worker blocks double-underscore requests from the public internet to user workers.
The platform can send HTTP requests to the user workers directly, bypassing the dispatch worker. We could have probably used other methods of delivery, such as queues, but this was very easy to implement and has been doing its job perfectly.

How we do cron jobs

Cloudflare limits the number of cron triggers per account to 250, so it’s not feasible to let each project define its own. Instead, the Fling platform defines only a single cron trigger, running every minute, that keeps a list of all projects’ cron triggers and when they last ran. For each one that’s due, it sends an internal request to the project’s worker and updates the table. Longer-term this will run into scaling issues, but for the time being, it works well and is very simple.

How we parse “declarations” for deploy, like the Discord commands

The project’s backend code can declare a variety of triggers that the platform needs to know about, so they need to be communicated during deploy. Examples of this are:

Cron schedules.
Discord “slash commands”.
An incoming email handler.

To collect these, we can run the backend with the runtime in a special “mode” that exits immediately and just prints out these declarations that it’s collected. We initially used regular expressions to parse out those declarations, but that felt dirty and was bound to lead to erratic behavior, so we fixed it and did it right.

How we deploy flings

When you deploy to Cloudflare, you usually use their Wrangler tool, which does pretty much everything for you. We also use Wrangler to deploy Fling itself, but we can’t use it for users’ apps because it doesn’t support deploying into Workers for Platforms. What we need to do instead is bundle the app (we use esbuild for that), and then send the bundle to Fling’s API, which in turn sends it to Cloudflare’s API that does the actual deployment.

One of our earliest flings needed a WASM module as a dependency. We thought this wouldn’t be a big problem, since Cloudflare supports WASM in workers. What we didn’t know was that this would require us to do some extra bundling tricks, because Cloudflare doesn’t support instantiating a WASM module from a blob, which would have let us bundle the WASM directly into the backend’s bundle. Instead, the WASM has to be deployed as a separate bundle, and the main bundle has to importit. To make that happen, we had to implement a simple esbuild plugin that marks WASM imports as “external” and then collects a list of all the WASM files that need to be co-deployed with the main bundle.

The next difficulty arising from that was that all those bundles could get pretty big, and Cloudflare workers have a hard 128MB heap limit. We didn’t even want to risk getting close to that, so we decided that all deployment paths had to be fully streaming, i.e., just pass the data through from the incoming request down to Cloudflare. We elevated that to a principle in Fling’s AGENTS.md:

**Workers (API and dispatch) have very limited memory.**
They cannot hold potentially large assets in memory.
Asset handling, especially uploads, must be streaming in the workers
and consume a bounded amount of memory.

Problems with Cloudflare

So far, we’ve run into surprisingly few problems with Cloudflare and the way we’re using it. The biggest one is a limitation of workers: the compressed bundle size can’t exceed 10MB, so no project can have a backend larger than that. We’ve run into this limitation once when generating PDF, because the agent wanted to use the jsPdf package, which alone blows past that limit. The solution was, like in many other cases, prompting: Fling’s skill now asks the agent to be very careful about the size of packages, and in particular tells it to use the smaller PDFKit for generating PDFs.

Development and testing

All of Fling’s code is written by coding agents, mostly Claude Code.
We review the code, but not line-by-line. Instead, we look out for:
- The shape of persisted data, because that’s hard to change later.
- The shapes of interfaces, because those are what abstracts the slop.
- Duplicate implementations of functionality, because that risks for those implementations to diverge.
We use dependency injection for almost everything, so we can unit-test easily.
We have hard rules that require that unit test coverage must never drop. Sometimes that requires the agent to add tests to unrelated code when making a PR. This is not a problem in practice.
We make sure architecture documentation is always kept up-to-date, both by pointing this out in our CLAUDE.md, but also by regularly making the agent check whether the docs are still up to date.

Integration tests and mock services

Fling has the ability to create fresh, unique deploys of itself fairly quickly and without much ceremony. We use this to have private instances that we can develop and try things on, and we also use it for integration testing: our integration tests create a new instance of Fling, signs up users, publishes projects, and tests a good portion of Fling’s features end-to-end.

One problem we ran into when building these tests was that we couldn’t programmatically create “apps” in Slack and Discord for this temporary Fling instance, and that, in any case, our tests shouldn’t rely on external services other than the main platform. To solve this, we built mock services that implement a sufficient subset of the services they replace in testing, which we found to be a very useful pattern. Our “fake” services are, naturally, also flings:

Fake Discord — a mock service built as a fling for integration testing

Takeaways

We’ve learned a lot from the process of creating Fling and from its adopters within the company. Here are some of our key takeaways.

What we’re learning

It’s really hard to explain what Fling is.
Fling is super attractive to “technical enough” people who have problems to solve. Removing the barrier to publishing unlocks their creativity, and they start and finish many projects.
Some of these people will push the coding agent to build things that seem almost unreasonable, like Stephen’s fling-in-fling. What to software engineers looks like a technical problem, to them, just looks like something that requires more talking to the agent.
People want to collaborate on flings on occasion, but it doesn’t happen all that often.
Better prompting is a good solution to many problems where we would otherwise be tempted to write code.
Cloudflare is a great infrastructure fit for deploying agentically built software.

How did we do with the constraints we set?

We managed to mostly stay within our constraints in creating Fling. The few small exceptions are:

We’re not fully single-platform: We’re using Resend for sending email-verification emails because Cloudflare doesn’t have a facility for that.
There is some shared infrastructure: Incoming HTTP requests go through a shared “dispatch” worker, which determines via the URL which project the request belongs to.
The other piece of shared infrastructure is plugins like Discord and Slack. There’s no easy way around this because there needs to be a single endpoint for webhooks for our Discord/Slack “apps”, and we can’t give users’ projects access to our Discord/Slack secrets.

Open problems, future work

We ask our users about any roadblocks they hit, and features they wish Fling had, or they find themselves building again and again.

Auth

The biggest feature still missing in Fling is arguably a built-in authentication and authorization framework, or some kind of integration that would make it easy to get something set up that allows logging in via Google, for example. Some Glide-internal Fling users resorted to setting up their own GCP project that their flings use to authenticate, but that’s not something we want a regular user to have to deal with.

Porting assistance

Users sometimes want to publish projects they’ve already built with Fling. However, Fling is not a generic deployment platform, so usually some amount of “porting” has to take place. At the moment, we tell those users to create a new Fling project, point Claude Code to their original project, and ask it to port it. In most cases, that works pretty well, but we should provide a more “integrated” solution, which might just involve extending the skill.

Durable execution

One more limitation of Cloudflare we wish didn’t exist is that Workflows aren’t supported in Workers for Platforms. We’ve wanted to support durable execution in Fling from the very start, and Workflows is Cloudflare’s implementation of that, but so far, we can’t use it, and we really don’t want to implement our own.

Collaboration

Fling is completely unopinionated when it comes to who edits code and where. We’ve found that in most cases, that’s a plus, because it lets people do what they already know, but it gets in the way when people want to collaborate on a fling. The first hurdle they have to clear is how to both edit the code. For somewhat technical users, the canonical answer to that is GitHub, and usually that’s good enough. The second problem is that if two different Fling users publish the same project, those end up as two completely separate deployments, because Fling doesn’t have a concept of shared access to a project.

For the time being, our skill is telling the agent that if the user wants to collaborate on a project with somebody else, it should recommend setting up a GitHub Action that auto-publishes the mainbranch, with the user’s credentials. That works well for users who are already somewhat familiar with git and GitHub, but is a stumbling block for the uninitiated. It’s not clear what we could offer here that’s simple.

Use Cases: How Fling is being used at Glide

Fling is already in heavy use across the Glide team. Both technical and less-technical team members have been building tools for use at work, creating software for personal experiments, and building for fun just to see what’s possible.

“Fling lets infrastructure get out of the way of you and your coding agent to bring ideas to life. The speed of iteration I have with Fling allowed me to learn more about prompting, skills, commands, version control, automated issue creation, and automated testing because I was more focused on empowering my agent than the technical specifics of the build.” — Evan Furniss, Solutions Expert at Glide

Sales — “Flingception” or “Fling-in-Fling”

Fling Build — a vibe-coding platform built on Fling

The most ambitious fling we’ve seen so far is Stephen Howie’s “Fling Build”, which is a full vibe-coding platform that is not only hosted on Fling but also deploys apps to Fling by running a full agent and sandbox, with Fling running in it in the user’s browser via WebContainers.

The sales team has been using it to prototype highly personalized apps for potential customers. It allows them to show potential customers a more tangible, shareable, and interactive example of what their final Glide build would look like. “What Howie created inside Fling EVERY sales org would use regardless of size,” said Katie Harkins, VP of Sales at Glide.

“One Sunday I built a web app with Fling, that itself can build and deploy other apps using Fling. What started as a ‘would it be possible…’ thought, soon became a tool used by our whole Sales team to send custom prototype apps to prospective customers.” — Stephen Howie, Customer Success & Solutions Lead at Glide

Customer Support

Santiago, on the support team at Glide, has been building multiple flings to help manage tickets more efficiently and in a more structured way. He created “ConvoIntel”, a Slack bot to analyze conversations, and “Support Analyzer”, which uses Groq in the background since Claude has no API key installed.

In addition, he’s created an API tester, a DNS checker, a JSON beautifier, and Workbench (a Retool clone) to help him build more tools more efficiently.

“Fling has been helpful because it removes the limitation of what I know how to build. I can go from ‘Can I do this?’ to actually testing it right away, instead of getting stuck trying to figure out how to build it first.” — Santiago Perez, Customer Service Specialist at Glide

Marketing

Cait Levin built an app with Fling to streamline the process of managing an extensive customer enablement email campaign. She had multiple team members working to create tips for using Glide, produce videos explaining them, create thumbnails for each video, assemble emails from a template, and then pull HubSpot data afterward to analyze email performance.

The Fling connects to HubSpot, ClickUp, YouTube, and Figma, and has ended up saving team members a considerable amount of time and manual labor. As a result, they have significantly upscaled the “Tips” campaign, which has been a huge success with customers.

“I was kind of surprised I couldn’t just say to Claude, deploy this online. I needed Fling to be able to do that. I think when people are making these kinds of local apps, if they’re actually useful, they probably will need to be online. There’s a big gap there, and I think Fling is a really important bridge.” — Cait Levin, Customer Enablement Lead at Glide

Try Fling

Get in touch