Now let's learn how to monetize our app using Clerk Billing. Let's run the following prompt. Using the Clerk Billing skill, turn on clerk billing for this app. It's organization based, so enable it for organizations and add a pro plan that orgs can subscribe to. And let's also add a safeguard.
This is configuration only. Enable billing and create the plan, Nothing else. Don't write any app code or build a pricing or billing screen yet. We'll do that next. So with this first prompt, we just want to enable clerk billing and create a pro plan.
And we can do that using the clerk billing skill which has access to the clerk CLI. Depending on the agent you have, it might ask you a question about the pro plan price. In my previous runs of this prompt, when I was just testing it out, it actually didn't ask me and it simply set the price to be $20. So if your agent didn't ask you, that's perfectly fine. If it did, choose any amount you think it's fair for this project.
Once the agent finishes, You shouldn't see any code changes in your project because this was pure configuration. So billing is now enabled for organizations within our project and a pro organization plan has been created with a slug pro and a $20 per month price. So if your agent failed to do this, don't worry, you can do that manually by going inside of your project in Clerk and head to Billing tab. Since I just enabled billing using the skill, if I refresh, this page is no longer going to show onboarding but instead it's going to show this. So if that's what you see it's configured correctly.
Otherwise go inside of the configure tab and in here you will also find billing. Make sure that enable organization billing is selected. From here you can also manage the plans. The free plan is here automatically. The one you should have added is the pro plan.
What's important here is that the key is pro, as this is how you can programmatically reference this plan. The description doesn't really matter, make sure it's publicly available and then just go ahead and set any price you want. Now let's build the UI and the reusable hook which we can use to tell us whether the current organization is in a pro plan or not. So once again, using the clerk billing skill, build the pricing page, put it in the app's dashboard route group so it sits inside the dashboard layout. Show the organization plans and let them subscribe and check out.
We are about to get a few things behind Pro. So also add a reusable hook in the workflow features hooks folder that tells the component whether the active organization is on Pro and can send someone to that pricing page to upgrade. You should now have two files created. The first one being the actual billing page located within the dashboard route group. You can now visit that page by going to localhost 3000, billing.
The UI can of course differ depending on the agent that you are using. But As long as you can see the pricing table being rendered and a prop for organization, it means the implementation is correct. The second file your agent should create is the use pro plan or any similarly named hook, which is used to verify whether the currently active organization is subscribed to the pro plan or not. The implementation of this hook can differ, but what's important is that you can find the logic which extracts the has util, which we can then use to check for the actual plan property. And we should check for the pro key because that's exactly what we named our plan.
So if you gave your plan another key, make sure to add it here. But if you're doing all of this in the same conversation, your agent will be aware of the name of your plan. And if this plan is not active, it should redirect the user to the newly created billing page. Now it's a personal preference whether you want this billing page to be accessible through the sidebar as well. Perhaps your agent already added it here.
There is another way users can access the billing configuration without visiting this page, and that is through the actual organization settings. So they can now find the billing in here. So that's why I feel like it's not necessary to create an actual sidebar item. Believe it or not, that's everything we need to pretty much progate anything you can think of. For example, how about we make the agent node, our most expensive node, only available to premium organizations.
Let's try the following prompt. The agent node is our most expensive node, so make it premium. Only organizations on the pro plan can add it to the canvas. Every other node stays free, so anyone can still build workflows. So I tell the agent go inside of the right sidebar, where the toolbar lists every node you can add.
For a non-pro organization, the agent node shows as locked and clicking it sends them to the upgrade instead of adding it. Use our new Progate hook. The output should look something like this. Instead of your toolbar, when you find the agent node, you should have some kind of indicator that it's currently locked for a free organization. So what my agent did is it added a simple lock on the right side and clicking on the agent doesn't add it to the canvas but instead redirects me to the billing plan.
There are many ways your agent could have implemented this. For example, my agent opted for a very simple set of premium nodes maintained inside of the right sidebar. Personally, I think it might be more modular to modify our node registry and then maintain which of these nodes is premium from here because then we can also gate it on the backend. But that is for further discussion with your agent. What I wanted to show to you is that you can now reliably use agentic coding with just a very simple setup and a set of clerk billing skills.
Now go ahead and proceed with the checkout and then go back inside of your canvas and once you try adding the agent node everything should work fine like it did initially. And then verify whether this is actually scoped per organization by switching to another organization and try creating a new workflow. And in here you should see the agent being locked once again, unless you go back to the previous organization in which you are on the pro plan, which makes the agent node available to everyone in the team. Now that you've learned how to protect the agent node, you pretty much have limitless options as to what else you want to monetize with clerk billing. For example, try asking your agent to only allow a total of five free workflows for every organization before being prompted to upgrade.
Or maybe allow an unlimited amount of workflows, but limit every canvas to a certain amount of nodes. Or maybe try to find attractive features, like session replay, and make that only available for premium organizations. The only limit is your imagination. And that's the whole point of agentic coding. A combination of being completely in control and saving ourselves from doing some tedious work by asking the agent to do it inside of a stable codebase, which means it's going to produce deterministic results.
I would highly advise you to try and experiment and protect some feature yourself. For example, I really like the idea of a session replay only being available to premium organizations because I feel like that's a premium feature. So I'm going to try it out using the following prompt. I want to show you one useful trick you can do with Clerk Billing. Go inside of your billing tab and find the organization in which you have subscribed to the pro plan.
Usually it can be a bit tedious testing out if a plan cancels or if it ends. Luckily, Qlerk gives you a super simple end subscription now, which can basically simulate unsubscribing, so you have a clean slate once again and don't have to create new organizations over and over again. And here's the result of the prompt which I ran. The replay row now also has the lock icon and when I click on it, I'm redirected to the billing page. Here's another idea.
So even though the agent node is technically locked, if I have an older workflow which already has the agent nodes, I can still run it. So let's create a prompt to fix that. Inside of my actions, stop the run workflow action from running a workflow that contains an agent node unless the organization is on the pro plan. Throw for a non-pro organization. Do this check in the action, not the run task.
The action has the clerk session and the has API util. The trigger.dev task has no auth context. Use the clerk billing skill for the plan check. So now even if you try running a workflow from previous session where you had access to the agent node it's going to throw an error. The agent node requires the pro plan.
Once you're done monetizing your features go ahead and stage, commit and push your changes.