PaywallOS: What an OpenVerb Domain Implementation Looks Like
This week, I want to show one of the clearest examples of what OpenVerb can look like when it is applied to a real software domain.
That example is PaywallOS.
OpenVerb provides a common way to define actions as verbs, validate inputs, apply policies, execute actions, and return receipts.
PaywallOS takes that model and applies it to:
- subscription tiers
- entitlements
- feature access
- usage limits
- upgrade decisions
The important part is that PaywallOS is not a separate idea from OpenVerb.
It is an example of what can be built on top of the OpenVerb execution model.
⸻
The Problem
Most SaaS applications start with simple subscription checks.
Something like:
if (user.plan === "pro") {
exportData()
} else {
showUpgradeModal()
}
That works at first.
Then the product grows.
Now you have:
- Free, Pro, and Business tiers
- usage limits
- unlimited features
- AI quotas
- custom entitlements
- different upgrade paths
- enterprise exceptions
Soon, feature-access logic starts spreading across the codebase.
function handleExport() {
if (!user.subscription) {
showUpgradeModal()
} else if (user.plan === "free") {
showUpgradeModal()
} else if (
user.plan === "pro" &&
exportsThisMonth >= 50
) {
showLimitModal()
} else {
exportData()
}
}
The application now has to understand pricing logic everywhere.
PaywallOS approaches this differently.
⸻
Step 1: Define Product Capabilities as Verbs
Instead of thinking first about buttons and routes, define the actual action.
{
"verbs": [
{
"name": "dashboard.view",
"description": "Access the analytics dashboard"
},
{
"name": "data.export",
"description": "Export reports and raw data"
},
{
"name": "ai.insights",
"description": "Generate automated AI insights"
},
{
"name": "ai.forecast",
"description": "Generate predictive forecasts"
}
]
}
Now these actions have stable identities.
data.export means one thing regardless of where the button appears.
ai.insights means one thing regardless of which frontend component triggers it.
That is the OpenVerb idea.
⸻
Step 2: Connect Verbs to Tiers
Now define which subscription tiers can execute which verbs.
Free
dashboard.view
Pro
dashboard.view
data.export
ai.insights
Business
dashboard.view
data.export
ai.insights
ai.forecast
team.collaboration
api.custom_keys
support.priority
At this point, the pricing model becomes much easier to inspect.
Instead of asking:
Where in the codebase do we check for Pro?
you can ask:
Which verbs does Pro allow?
That is a much cleaner boundary.
⸻
Step 3: Add Usage Policies
Not every entitlement needs to be unlimited.
For example:
dashboard.view
Free: unlimited
Pro: unlimited
Business: unlimited
data.export
Free: denied
Pro: 50/month
Business: unlimited
ai.insights
Free: denied
Pro: 20/month
Business: unlimited
ai.forecast
Free: denied
Pro: denied
Business: unlimited
Now the system can answer more than a simple yes or no.
It can determine:
- whether the action is included
- whether a limit applies
- how much usage remains
- whether the user needs to upgrade
- whether the monthly quota has been reached
⸻
Step 4: Let the UI Describe the Action
The frontend can simply declare what action the user wants to perform.
Export
Generate Insights
Forecast
Now the UI does not need to understand the entire pricing system.
It only needs to say:
The user wants to execute data.export.
PaywallOS can evaluate the entitlement.
⸻
Complete Example
Suppose Alex is on the Free plan.
Alex clicks:
Export
The system evaluates:
User: Alex
Tier: Free
Verb: data.export
Decision: DENY
Reason:
data.export requires Pro or Business
The application can show the appropriate upgrade experience.
Now Alex upgrades to Pro.
The exact same button remains:
Export
But the evaluation changes:
User: Alex
Tier: Pro
Verb: data.export
Usage:
17 / 50
Decision:
ALLOW
The export runs.
Usage becomes:
18 / 50
No new conditional.
No change to the button.
No duplicated subscription logic.
⸻
When the Limit Is Reached
Eventually Alex reaches:
50 / 50
The next request can return:
Decision: DENY
Reason:
monthly_limit_reached
Limit:
50
The system can then show a quota message instead of an upgrade message.
Same verb.
Different policy result.
⸻
The Same Pattern Works for AI Features
Consider:
Analyze Dataset
A Free user:
DENY
Upgrade required
A Pro user with 7 of 20 uses consumed:
ALLOW
Usage: 8 / 20
A Pro user at the limit:
DENY
Monthly limit reached
A Business user:
ALLOW
Unlimited
The feature remains:
ai.insights
The policy determines whether it can execute.
⸻
The Architecture
The complete flow looks like this:
UI
verb="ai.insights"
↓
OpenVerb
What action is being requested?
↓
PaywallOS
Who is requesting it?
What tier are they on?
Is the verb included?
Does it have a limit?
How much has been used?
↓
Decision
ALLOW
DENY
UPGRADE
LIMIT_REACHED
↓
Application
Execute the action
or
present the appropriate paywall
This separation is the important part.
⸻
Why This Matters Beyond Paywalls
PaywallOS is interesting because it demonstrates that OpenVerb does not need to directly implement every domain.
OpenVerb provides a common execution language.
The domain system adds its own interpretation.
PaywallOS asks:
Who is allowed to execute this verb?
A GIS system could ask:
Which mapping environment can execute this verb?
An enterprise agent system could ask:
Which agent is authorized to execute this verb?
A workflow engine could ask:
Is this verb allowed at the current workflow stage?
A physical-device runtime could ask:
Which device can execute this action?
Same execution model.
Different domain.
⸻
OpenVerb as the Shared Layer
You can think of the architecture like this:
OpenVerb
↓
PaywallOS
But that same model could also support:
OpenVerb
↓
GIS execution layer
or:
OpenVerb
↓
CRM execution layer
or:
OpenVerb
↓
Browser automation
or:
OpenVerb
↓
AI-native IDE
That is the larger direction.
OpenVerb defines the common language of execution.
Domain systems build on top of it.
⸻
The Bigger Idea
Traditional software often looks like:
User clicks button
↓
Application runs custom logic
An OpenVerb-style system can look more like:
Human or AI requests an action
↓
Action is represented as a verb
↓
Policy determines whether it can execute
↓
The correct runtime executes it
↓
A receipt describes what happened
That gives AI systems a structured boundary between:
deciding what should happen
and
actually making it happen
PaywallOS is one concrete example of that idea.
⸻
Explore It
PaywallOS:
https://paywallos.openverb.org
OpenVerb:
Install:
npm install openverb
or:
pip install openverb
If you are building AI agents, SaaS platforms, developer tools, automation systems, or domain-specific execution environments, I would be interested to see what this model could look like in your architecture.
OpenVerb: open execution for AI.
OpenVerb #AI #OpenSource #DevTools #AIAgents #SaaS #TypeScript #Python
Top comments (0)