Concepts

What's a Rough Feature

What is a Rough Feature?

A Rough Feature is a small piece of working software that someone built without writing code, running inside a host product on an embedded surface. To the person using it, it looks like the rest of the product. It runs in an isolated frame, and it can only do what the host product allowed.

Every Feature lives inside a Surface, a region the host product has opened up to Rough. You use surfaces to decide where extensions can appear, what context they get, and what they can do.

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 what the host hands it. You define what data and actions a surface exposes, and the Feature works from that.
Call actions the host defined. Expose a "create task" or "update record" action and a Feature can use it. You decide which actions exist, and a Feature can only use those.
React to live changes. A Feature can subscribe to host data and stay in sync as that data changes.
Show up in your dashboard. Rough lists every Feature, so you can see who built what, who's using it, and where to take it next.

What a Rough Feature can't do

Rough stops Features doing several things, and stops them in the architecture rather than in a policy document.

It can't reach into the host app's internals. Features run in an isolated frame and only see what the host passes in.
It can't make arbitrary network calls on the user's behalf. A Feature reaches the host through the tools the host registered, and nothing else.
It can't touch other Features or other Surfaces. Each Feature is scoped to its own Surface.
It won't replace your product engineering. Rough handles the long tail, the small, lateral, situation-specific extensions. Anything central to the product still belongs in your codebase.

What kinds of things people actually build

People reach for Rough when they have a small, specific need that isn't worth a roadmap conversation but annoys them enough to want fixed. Most of what they build looks like one of these:

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?

Both run sandboxed code inside a host, so the mechanism is similar. But developers write plugins and users install them, whereas users build Rough Features themselves, inside the product, while they're using it. You don't have to run a marketplace or review submissions.

Won't customers build dangerous things?

They can only do what the Surface lets them do. You define the Surface: here's the context, here are the actions, and nothing else gets through. If you don't expose "delete user" as an action, no Feature can call it.

What happens when the host product changes?

Treat a Surface like an API. Existing Features were built against the shape you gave them, so changing what a Surface exposes can break them, the same way changing a response shape breaks a client. Rough doesn't version Surfaces for you today. Keep the surface key stable, add tools rather than removing them, and check the management UI for what's been built on a Surface before you change it.

Can the same Feature work in multiple places?

A Feature is scoped to its Surface. If two of your Surfaces expose compatible tools, someone can build a Feature that works in either, but Rough won't move a Feature across Surfaces on its own.

What about performance?

Every Feature runs in its own frame, separate from the code your engineers wrote. A slow Feature slows down its own Surface and leaves the rest of the product alone.

Is it AI-built?

Rough uses AI to build Features, so a user can describe what they want and get something working without writing code. What keeps that safe is where the code lands: the same isolated frame and the same tool list apply, whoever or whatever wrote it.