Most sites need one or two, not ten. Webflow Apps extend the Designer or connect your site to another service, and the good ones remove real work. The trap is treating the marketplace like an app store and installing anything that looks useful, which adds weight and complexity you will maintain forever.
We take over Webflow projects fairly often, and the pattern repeats. A handful of apps installed by different people over two years, half of them abandoned, none of them documented. Nobody can say what would break if they were removed, so nobody removes them.
So this is less a list of recommendations than a way of deciding. What an app actually is, what it can reach inside your site, what it costs you in performance and risk, and when writing five lines of your own code is the better answer.
An app is a reviewed, installable extension distributed through the Webflow App Marketplace. Custom code is a snippet you paste into your own site settings. The difference is that an app is built against Webflow's official APIs and goes through Webflow's review, while custom code is entirely yours to get right.
That distinction has real consequences. Custom code runs on your published site and can only do what a browser script can do. An app can reach much further, into the Designer itself or into your site data, using interfaces Webflow deliberately exposes for the purpose.
Apps also update independently of your site. When the developer ships a new version, you get it after Webflow reviews it. That is convenient when the app is well maintained and a liability when it is not, because a dependency you do not control now sits inside your build process.
Custom code has the opposite profile. It never changes unless you change it, which makes it predictable and makes it rot. Neither is better in general. Apps suit recurring work, and custom code suits one specific behaviour on one specific site, which is roughly how we split them in our thinking about third-party scripts generally.
A wider range than most people realise. Webflow groups them into categories covering AI, analytics, asset management, automation, compliance, content management, customer support, data sync, design, development, ecommerce, forms, localisation, marketing, SEO, user management, and general utilities.
The practical grouping is simpler than the category list. Some apps run inside the Designer and change how you build. Some run in the background and move data between your site and another system. And some do both, adding a panel in the Designer while also syncing something server side.
The Designer side is where the marketplace is most interesting, because that work used to be entirely manual. Importing a design, generating a component set, pulling in an asset library, and organising pages are all things that used to eat afternoons.
The background side is more familiar territory, because it overlaps with tools you already use. Automation platforms and CRMs have Webflow apps that do roughly what their integrations always did, just with a cleaner install path than a webhook you configured by hand.
They run as small web apps inside the Designer. Webflow's developer documentation describes Designer Extensions as single page applications that run inside a secure iframe within the Webflow Designer, talking to the canvas through client side Designer APIs rather than touching your site directly.
The sandbox matters. An extension is not running with free rein over your project. It sits in an isolated frame and asks Webflow to do things through a defined interface, which is why a badly behaved extension is far less dangerous than a badly behaved script pasted into site settings.
What that interface allows is genuinely broad. Webflow's documentation says extensions can generate complex components, populate data from third party sources, or build entire page structures with a single click. They can apply and maintain consistent branding, manage variables and swap themes, connect to external asset libraries, optimise images, and add and organise pages and folders.
Read that list again and the appeal becomes obvious. These are exactly the repetitive, click heavy tasks that make a large build slow. An extension that builds a page structure in one action is not a novelty. It is an afternoon back.
The ones that remove a task you do on every project. On the marketplace right now the highest adoption apps are the ones that solve exactly that, with Figma to Webflow, Relume Site Builder Import, SVG Import, and Zapier all listed with more than 5,000 users. Adoption at that level is a reasonable signal.
Design import is the clearest win. Moving a Figma file into Webflow by hand is slow and error prone, and an import tool that gets you eighty percent of the way there changes the economics of a build. It will not produce the clean class structure you want, so treat it as a starting point rather than a finished layout.
Component libraries are the second category we actually use. Finsweet Components sits in the marketplace alongside the wider Finsweet ecosystem, and if your team already builds to a naming convention it fits neatly. The reasoning behind that convention is in our piece on how Client-First makes Webflow projects better.
Automation is the third. Zapier and Make both have marketplace presence, and for anything involving form submissions going somewhere useful they beat writing your own webhook handling. We wrote about where that approach pays off in our guide to automating web workflows with Zapier and Make.
Beyond those, the honest answer is that it depends on your stack. If you run HubSpot, the HubSpot app is worth it. If you do not, it is dead weight. There is no universal list, and anyone offering you one is guessing about your business.
It depends entirely on whether the app touches your published site. Designer Extensions do not, because they run inside the Designer while you build and ship nothing to visitors. Apps that add tracking, chat, or embedded widgets absolutely do, because they load code in every visitor's browser.
This is the single most useful distinction to hold onto, and almost nobody makes it. You can install as many Designer side tools as you like with zero performance cost to your visitors. It is the runtime integrations that need discipline.
The scale of that risk is easy to underestimate. The HTTP Archive Web Almanac 2025 third parties chapter found that over 90% of pages load third party resources, with a median of 83 third party requests on desktop and 79 on mobile. Each of those started as one reasonable decision.
So our rule is asymmetric on purpose. Designer tools get a generous trial, because the downside is only clutter. Anything that injects a script into the published site has to justify itself against a measured performance cost before it stays.
Safer than arbitrary custom code, though not risk free. Webflow reviews apps before they reach the marketplace, and its developer documentation confirms that updates go through the same review process as the initial submission. Private apps are reviewed just like public ones, so distribution method does not change the bar.
The marketplace also distinguishes public from private apps. Public apps are listed and discoverable by all users. Private apps are not listed, and the developer controls who can install by sharing a direct install URL. If someone sends you an install link for something not in the marketplace, that is a private app rather than a red flag by itself.
The real risk is not malice. It is access. An app that can read and write your site data has meaningful reach into your business, and that permission persists long after the person who installed it has left. Review installed apps when staff change, the same way you would review any other account access.
Abandonment is the other quiet risk. An app that stops being maintained does not announce itself. It simply stops working one day when Webflow changes something underneath it, usually at an inconvenient moment. Prefer apps from teams with a real business behind them.
When the app does one small thing you could write in an afternoon. Installing a dependency to solve a twenty line problem is a bad trade, because you have swapped code you control for a relationship you do not. The dependency will outlive its usefulness and nobody will dare remove it.
The other case is anything core to how your site works. If a feature is central to your product, owning it matters more than shipping it quickly. A form that feeds your sales process is worth building properly. A nice to have widget in the footer is not.
We also skip apps that duplicate something Webflow now does natively. The platform has absorbed a lot of functionality that used to require third party tools, and every generation of that leaves behind apps solving problems that no longer exist. Check the native feature set before you search the marketplace.
The reverse case is worth naming too. If an app saves an hour on every project and you run twenty projects a year, that is worth paying for without much analysis. Speed of delivery is a real business advantage, and tools that buy it back are rarely the expensive part of a build.
Ask four questions. Does it touch the published site or only the Designer? How many hours does it actually save per project? What happens if it disappears tomorrow? And can you explain to a new team member what it does in one sentence?
That last question does more work than it looks like. If nobody can explain what an app does, it is not being used deliberately, and something not being used deliberately is something to remove. We apply the same test to custom code and to analytics tools.
Then set a review date. Once or twice a year, list every installed app across your workspace and ask the four questions again. Apps accumulate silently because uninstalling feels risky, so the only reliable defence is a scheduled decision rather than a spontaneous one.
Across our own projects the installed app list stays short on purpose. Fewer moving parts means fewer things that break during a handover, and handover quality is what decides whether a site stays good after we leave.
Open your Webflow workspace and list what is installed. For each one, decide whether it touches the published site and whether anyone would notice if it vanished. Remove what fails both tests, and keep the ones that save real time on every build.
If you are starting fresh, resist installing anything until you hit an actual friction point. Build one project the manual way, notice where the hours go, then go looking for a tool that removes that specific hour. Solving problems you have beats collecting tools for problems you might.
If you are unsure whether an app is doing something important on a site you inherited, that is a genuinely hard question to answer alone, and we are happy to work through it with you. Come find us at phoenix.studio and tell us what you are looking at.
Tell us where you want to go. We'll tell you how we'd get you there.