When a customer asks for one upper-plan feature: decide the undo first
Whether to open an upper-tier feature for one account is decided by the undo, not by implementation speed.
Key points
- Pick by the undo, not by the speed
- Grant in code; log it in one table
- In the plan, every subscriber gets it
- Plan changes land next billing period
Contents
The three ways differ in how you undo them
A&A perspective
If you sell anything on a monthly basis, the request always arrives in the end: "Could we have just that one feature from the upper plan?" It happens the same way on a maintenance retainer for client work and on a plan for a tool you built yourself.
A&A perspective
Each time, most companies add an exception to their own code for that one account. Below, that exception is called a branch. Because the record of who was given what lives only inside the code, neither a price rise nor the retirement of a feature can be carved out later.
A&A perspective
There are three ways to go. Add a branch in your own code and open the feature for that one account. Add the feature to the plan definition. Or build a separate plan that contains it.
A&A perspective
Automate & Augment (A&A), which writes this article, takes on the pricing and the feature make-up of AI services, from design through to implementation. Seen from there, the three are usually chosen by which one is fastest. Adding one line of branching is the fastest, so one-off grants keep going.
From the sources
Stripe, which takes on payments and billing, publishes documentation on deciding which customers can use which features from the billing side. The first use it lists is being able to launch, change and experiment with pricing without rewriting the codebase.
From the sources
A customer story published by the same company covers Lovable, a service where people build apps and websites by chatting with AI. Its co-founder says that adding new products has become much easier: what used to take custom code is now a quick Stripe setup.
A&A perspective
The work of granting is small on either path. Writing a branch and declaring a feature on the billing side are both small pieces of work in themselves. Choose by speed and the three paths look identical.
A&A perspective
The gap opens when you undo. A grant made in your own code is closed by editing that code. A feature added to the plan definition is taken back by removing it from the product on the billing side. A separate plan is undone by no longer selling that plan, and the people already on it keep using it until their contract changes.
A&A perspective
Because the undo steps differ across all three, that is where the choice is made.
Grant in code and keep one table until the third ask
A&A perspective
One note first: there is a stage at which thinking about the three options is too early. You have only a handful of customers, and what counts as a feature is still moving.
A&A perspective
Declaring features on the billing side at that stage makes the naming work itself expensive. The way you sell has not settled, so six months later you will be cutting the lines somewhere else.
A&A perspective
A&A draws the line at the third time the same request arrives. Up to the second, open the feature in your own code. In exchange, write down who was given what, and when, in a single table.
Hypothetical example
Say a few people sell an AI transcription service. The table has five columns: the account, the feature opened, the date opened, the original plan, and the condition for taking it back. A row is added only when a request comes in.
A&A perspective
What the table buys you is the ability to count the requests. Branches in code have to be hunted down before they can be counted; a table is counted by its rows.
A&A perspective
A feature that reaches a third request is no longer one account's wish. Only then do you consider adding it to the plan definition or building a separate plan.
A&A perspective
Conversely, a feature that never reaches a third request can stay a one-off. There is no reason to put an exception built for one account onto everyone's pricing table.
| The way you choose | Who it reaches, and when | What the undo takes |
|---|---|---|
| Grant it in your own code | Only the one account, from the moment you edit the code | Edit that code to close it |
| Add it to the plan definition | Every existing subscriber of that plan, from the start of the next billing period | Remove the feature from the product on the billing side |
| Build a separate plan that contains it | Only those who subscribe to that plan from now on, from activation | Stop selling that plan; people already on it keep it until their contract changes |
Adding it to the plan reaches every existing subscriber
From the sources
Stripe's documentation gives a name to the state in which a given customer can use a given feature: it calls that an entitlement. When a customer purchases or subscribes to a product with an attached feature, an entitlement for that customer and that feature is created, the documentation says.
From the sources
It also describes the mechanism as a way to map the features of your internal service to products on the billing side, and states that a single feature can be attached to several products.
A&A perspective
Here is where the one-off grant differs. Opening a feature in code reaches one account. Adding the feature to the plan definition reaches every person subscribed to that plan.
From the sources
The Lovable story published by the same company describes the plans at launch: a free tier for individuals and paid tiers, where the higher tiers carried graduated levels of monthly usage credits and specific features as well. It goes on to say that the offering was later widened to plans with shared workspaces for collaboration and higher resource limits.
A&A perspective
A&A reads that sequence as answering demand by adding plans rather than opening features account by account. The page is published by the payment platform itself as a customer story, not by an independent reviewer. It also describes a company selling its own product at a far larger scale than A&A. It does not transfer as-is to a business with around ten customers. What transfers is only the idea of keeping how much is used and which features are available on separate axes.
A&A perspective
What you meant as one account becomes a promise to everyone. That difference also gives you a reason to decline. You lose the ability to say "we will open it for you alone," and gain the ability to say "we will consider whether to add it to this plan."
A&A perspective
Choose the separate-plan route and the audience narrows further. It reaches only the people who subscribe to that plan from now on. In exchange, the pricing table gains one more line.
A&A perspective
Naming features carries a constraint this article does not cover.
From the sources
Stripe's documentation says a feature is created with a name and a lookup key that is unique to it. The name can be edited later, it says, but the lookup key cannot be edited after the feature is created, and an archived feature's lookup key can be used again.
A&A perspective
How to decide those names and keys is covered in the existing article "Before adding a paid AI SaaS plan: match the pricing table to real access."
A change on the plan side lands at the next billing period
From the sources
Stripe's documentation carries a note about when a change takes effect: for existing subscriptions, an active entitlement for a product feature change is created at the start of the next billing period.
From the sources
New customers are different. When a subscription is first activated, entitlements are created for the features that customer is subscribed to, the documentation says.
A&A perspective
So "open it right now" and "add it to the plan" are two different promises. A grant in your own code works from today. A feature added to the plan reaches an existing subscriber from the start of that person's next billing period.
Hypothetical example
Take an invented date. A customer is billed on the tenth of each month, and today you add the feature to their plan. The feature appears on their screen next month, on the tenth. If you want the customer using it from the meeting room, adding it to the plan will not arrive in time.
From the sources
There is also an account of stopping. The documentation describes an operation that puts a feature away so it is no longer in use; it calls this archiving. An archived feature can neither be edited nor added to any new product. It still creates entitlements, however, as long as it remains attached to existing products. Archiving also cannot be undone, the documentation states. Removing a feature from a product is a separate operation.
A&A perspective
What this says is that deciding to stop selling a feature and deciding to take it back from someone you already promised it to are two different decisions. Stopping the sale does not remove it from the hands of those who already bought it.
A&A perspective
To take it back, you remove the feature from the product. The note says a product feature change lands at the start of the next billing period, so removal reads as included there. It does not, however, name the removal case. A&A does not treat that as settled, and keeps it as an item to check against the current documentation before implementing.
A&A perspective
For a grant made in your own code, the undo touches only that code. If the date opened and the condition for taking it back are written in the table, the decision to undo is made on that table too.
Summary
A&A perspective
When one account asks for an upper-tier feature, the three ways are chosen by the undo steps, not by how fast you can ship.
A&A perspective
Up to the second request, a one-off grant is fine. In exchange, write down who was given what and when, and what would make you take it back, in a single table.
A&A perspective
Add the feature to the plan definition and the audience is not one account but every existing subscriber of that plan.
A&A perspective
When you change a feature on the plan side, it reaches existing subscriptions from the start of the next billing period. A promise to have the customer using it from the meeting room cannot be kept on the plan side alone.
When one account asks for an upper-tier feature, the three ways are chosen by the undo steps, not by implementation speed. A grant in your own code is closed by editing that code; a feature added to the plan definition is taken back by removing it from the product on the billing side; a separate plan is undone by no longer selling it. Up to the second request, a one-off grant is fine, as long as who was given what and when, and what would make you take it back, is written in a single table. Add the feature to the plan definition and the audience is every existing subscriber of that plan. A change on the plan side reaches existing subscriptions from the start of the next billing period, so a promise to have the customer using it from the meeting room cannot be kept on the plan side alone.
FAQ
Can a feature granted one-off be added to the plan definition later?
Yes, and that is the natural order. From the moment you add it, though, every existing subscriber of that plan gets the same feature, each from the start of their own next billing period. Remove the branch you wrote for the first account only after confirming the feature has arrived, so that the same access is not opened in two places.
Is there any evidence behind the number three?
Not in the sources. It is a line A&A draws where the weight of naming features balances the weight of carrying one-off branches. A business with many customers can draw it at the second request; one that has just started can draw it at the fifth. What matters is less the number than being able to count the requests at all.
Does the same thinking apply to a maintenance retainer for client work?
The thinking is the same. What differs is that declaring features on the billing side may not be available to you. In that case the second and third options become amending the schedule attached to the contract, or creating a different contract type. Choosing by the undo, and holding the first two requests in a single table, do not change.
Sources & editorial note
Primary pages read for this article. Publication dates below belong to the sources; access dates record our research.
- Entitlements
Stripe · undated documentation page; no publication or update date shown
Accessed 2026-10-22 - Riding the AI boom: How Lovable grew into a vibe-coding juggernaut with Stripe
Stripe · undated customer story page; no publication or update date shown
Accessed 2026-10-22