Programmable products

Make your product programmable

Your customers want it to work their way. Mable lets them extend it, by hand or with their agents, inside the boundaries you declare. Every change is tested, signed off by a person, and reversible.

Apply as a design partner

We're working with a small number of B2B SaaS teams this quarter. Pilot pricing, with our engineers in your repo.

Open-source SDK · Works with any MCP-compatible agent · Rules run in your process, not ours

In the last year Shopify, Salesforce and HubSpot each shipped ways for agents to build customizations inside their products. Mable brings that capability to every other SaaS team.

Your biggest customer wants one more rule. So does your next one.

Every enterprise deal comes with a list. Route these tickets differently. Block that deal stage without sign-off. Price this account another way. Each request is small, so you build it. Then the flags pile up, the old code paths never die, and your roadmap starts to look like a services queue.

Your customers aren't going to stop asking. Their admins already use Claude, ChatGPT and Cursor, and they've noticed that writing the logic is the easy part now. What's missing is a safe place inside your product for that logic to run.

You could build that place yourself: a runtime, isolation, approvals, versioning, audit, agent tooling, an admin UI. That's a platform team and a year you don't have.

How it works

You declare the surface. Their agents shape the rest.

01 / Declare

Declare exactly what's programmable

Pick one decision in your product, like a stage change, an assignment or a validation, and publish it as a versioned surface. Our SDK proposes the hook and the contract as a normal pull request. Your engineers review it, and anything it can't cover is listed explicitly.

02 / Draft and test

Customers bring their own agent

Admins ask whatever agent they already use. It discovers your surfaces through MCP-compatible tools, drafts the rule, and runs it against fixtures in a dry run. Nothing touches production.

03 / Approve

A person signs off. Every time.

Agents can propose but never approve. The admin sees what changes, for whom, what happens if it fails, and how to undo it. For sensitive surfaces, you can require your own sign-off too.

Runs before the write commits

Approved rules run in your process, at the authoritative operation, before the change is saved. There's no network call and no model call on that path, and rules keep working if our control plane goes down.

Every version, on the record

Signed, immutable versions. Decision traces. One-step rollback. When your next release renames a field an extension depends on, CI fails the build and tells you which extension and whose.

What we'll prove with you

We measure every design-partner integration against a competent manual build, using real engineer-hours including fixes. Our bar:

  • At least 50% less engineering effort than building it yourselfTarget
  • First customer rule proposed, dry-run and activated within 30 minutes of the surface going liveTarget
  • Zero known critical bypasses at launch, with every enabled write path testedLaunch bar
  • p99 under 5 ms for rule evaluation on the hot pathTarget

These are targets, not results. We'll publish the measured numbers, including the ones we miss.

Questions engineering and security leads ask first

Is it safe to run customer logic in our transaction path?

On the synchronous path, extensions are a restricted rule language evaluated locally. There's no filesystem, no network and no model call, and there's a hard deadline you set. You choose the fail mode. Your own auth and invariants always run first and always win. There's a kill switch per surface.

How much integration work is this?

For each surface, our SDK proposes the hook and contract as a pull request that goes through your normal review and CI. The design-partner pilot exists to measure exactly how long this takes in your codebase, with our engineers alongside yours.

Will it catch every path that writes to that data?

Not automatically, and we won't claim it does. The scanner finds the write paths it can, flags the ones it can't, and your engineers confirm coverage before anything is enabled.

Our customers already use our API and Zapier. Why this?

If async automation solves the request, keep using it. Mable is for the requests it can't solve: decisions that have to happen before a change commits, and behavior that has to feel native.

What if we leave?

Surface contracts, extensions and version history all export as plain JSON. Active rules keep running locally until you remove the SDK.

Do our customers need to be technical?

No. They describe what they want to their agent and review a plain-language sign-off screen. If they don't use an agent, you can embed our settings and approval UI in your product.

How Mable compares with webhooks, an in-house build and a code sandbox
CapabilityWebhooks / iPaaSBuild it in-houseCode sandboxe.g. Workers for PlatformsMable
Runs before the write commitsNoYesPartial: you build the hookYes
Customer's own agent can authorNoYou build itYou build itYes
Human sign-off, versions, rollbackNoYou build itYou build itYes
Contract drift caught in CINoYou build itNoYes
Time to first surfaceDaysQuartersWeeksBeing measured in pilots

Pick one decision your customers keep asking you to change

Bring it to a 30-minute call. We'll look at your last five custom requests, tell you honestly whether Mable fits, and if it does, scope a pilot around that one surface.

Design partners

Design-partner application

For B2B SaaS teams with an API and a backlog of custom requests. No sales deck.

One per line, in plain language. For example: "Block moving deals over $50k to Won unless Legal approved."

Formspree receives applications for us. Read the privacy notice.