Concepts

Features

A Rough Feature is a small, user-built extension that runs inside a host product. Here's what they can do, what they can't, and the questions we hear most often.

What is a Rough Feature?

A Rough Feature is a self-contained piece of functionality that someone built without writing code, and that runs inside a host product on top of an embedded surface. From the user's perspective it's just another part of the product. Behind the scenes it's a sandboxed extension that the host product chose to allow.

Each Feature lives inside a Surface — a region the host product has explicitly opened up to Rough. Surfaces are how vendors stay in control of where extensions can appear, what context they receive, and what actions they can take.

What a Rough Feature can do

• Render UI inside the surface. Buttons, forms, lists, charts, custom views — anything you'd build with a normal web component.
• Read context the host has provided. The host app defines what data and actions a surface exposes. The Feature uses that context to do its work.
• Call host-defined actions. If the host product exposes a "create task" or "update record" action, a Feature can use it. The host decides which actions exist; the Feature can only use what's offered.
• React to live changes. Host data can be subscribed to, so a Feature stays in sync as underlying state changes.
• Be discussed, iterated on and refined. Features are managed in Rough's product management dashboard, so you can see who's using what, who built it, and where to take it next.

What a Rough Feature can't do

Rough is intentional about what Features are not allowed to do. The architecture is the constraint, not the policy.

• It can't reach into the host app's internals. Features run inside an isolated runtime. They only see context the host explicitly passes in.
• It can't make arbitrary network calls on the user's behalf. The Feature interacts with the host through a defined set of actions. If it isn't in that set, it isn't reachable.
• It can't modify other Features or other Surfaces. Each Feature is scoped to its own Surface.
• It isn't a replacement for core product engineering. Rough is for the long tail — the small, lateral, situation-specific extensions. Anything central to the product still belongs in your main codebase.

What kinds of things people actually build

The pattern is usually the same: someone has a small, specific need that isn't worth a roadmap conversation but is annoying enough to want to fix. Common shapes include:

• A custom view of existing data, filtered or grouped a particular way.
• A small workflow that strings together a few existing actions.
• A form that captures something the standard product doesn't capture.
• A dashboard or report that doesn't fit the built-in templates.
• A rough-cut prototype of an idea before deciding whether to build it properly.

Common questions

Is this just plugins again?

The mechanism is similar in spirit — sandboxed code running inside a host — but the experience is different. Plugins are usually written by developers and installed by users. Rough Features are built by users themselves, inside the product, in moments. The host vendor doesn't have to maintain a plugin marketplace or review submissions.

Won't customers build dangerous things?

They can only do what the Surface lets them do. A Surface is a contract: here's the context, here are the actions, that's it. If you don't expose "delete user" as an action, no Feature can call it. The host vendor designs the contract.

What happens when the host product changes?

Surfaces are versioned in the same way your APIs are. If you change what a Surface exposes, existing Features built against the old contract continue to see the old shape until they're updated. The Rough management UI is where you observe which Features are still on which contract.

Can the same Feature work in multiple places?

A Feature is scoped to its Surface. If you have two Surfaces with compatible contracts, a Feature can be designed to run in either, but Rough doesn't auto-promote a Feature across boundaries. That's deliberate.

What about performance?

Features run in their own sandboxed runtime, separate from your host app's main thread. A poorly built Feature affects its own Surface, not the rest of your product.

Is it AI-built?

Rough uses AI to power the Feature builder, so users can describe what they want and get something working without writing code. The AI generates the Feature; Rough's runtime is what makes it safe to run inside your product.

Next

• How RAF works — the architectural pattern that powers all of this.
• Security — what's isolated, and what isn't.