Pricing

Why it costs this little

$99 a month is not a launch discount, a loss leader, or the first step of a land-and-expand plan. It is roughly what we would pay for this ourselves, comfortably, forever, without having to think about it.

The mission is distribution

We think this practice raises a team's security posture by an order of magnitude, using nothing but the directories and systems already in place. No new agents, no new identity store, no re-architecture: the groups exist, the roles exist, and the change is that membership stops being permanent.

That improvement only happens if the thing gets installed. Every dollar of price is a filter on how many teams ever try it, and a security control that a team declines on budget grounds protects nobody. So the price is set where the answer is obviously yes — small enough to approve without a committee, and small enough that nobody has to predict how much they will use it first.

What we refuse to do

We have been on the buying side of predatory vendors. Hidden fees. Usage meters nobody could have forecast. The "true-up" call twelve months in, where the number has moved and the leverage has moved with it, because by then you are migrated and they know it. That is the exact opposite of how we want to do business, and it is worth naming rather than implying:

• No true-ups. The bill is the bill.
• No charging for single sign-on. It is included on every tier, including the cheapest one. Charging a security tax for the control your security team requires is the practice that made "SSO tax" a phrase.
• No pricing that punishes doing the right thing. Nothing gets more expensive because you added another system, audited more often, or gave more people the read-only access that removes their need for write access.
• Nothing that can block a revocation. No plan limit, quota or billing state stops access from expiring. A cap that could block revocation would convert every temporary grant into a permanent one — a billing decision silently becoming a security incident. That rule is written into the product, not just the policy.

"Couldn't we just build this ourselves?"

Honestly: yes. A competent engineer with modern tooling can build the first version of this in a couple of weeks, and it will demo beautifully. Requesting access, approving it, writing a group membership — that part is genuinely not hard, and we would not insult you by pretending otherwise.

The cost is not the first version. It is the second year, and it is concentrated in the parts nobody scopes:

• Removal that cannot fail quietly. Granting is a request-response you watch succeed. Revoking happens hours later with nobody looking, and a removal that silently no-ops leaves permanent access that everyone believes is temporary. The entire product is built around that path being the one that never breaks.
• Reference-counted removal. Two packages grant the same group, one expires — take the membership away and you have just revoked access the person legitimately still holds. Get this wrong and people lose access mid-incident.
• Retries that are safe to repeat. Directory APIs fail halfway, rate-limit, and occasionally lie about what they did. Every write has to be repeatable without doubling anything.
• Approvals that cannot deadlock. The named approver leaves the company and every request routed to them is stranded, permanently, with no error anywhere. There is a whole category of these, and each is discovered in production.
• An audit record that answers the real question. Not "who signed in", but "who could have changed this, when, for how long, and who approved it" — which has to be true across every system, and has to survive a package being renamed or deleted afterwards.
• Each directory's particular weirdness. Entra, Okta, Google Workspace, GitHub, AWS IAM and on-premises AD each model groups slightly differently, and each of those differences is a bug you find once.

None of that is intellectually difficult. All of it is a year of somebody's attention, forever, on a system that is not your product. We have priced this so that maintaining your own version is the more expensive option — which is the only honest way to win that argument.

We may be early, but we are not wrong

As the company grows, new pricing may well be higher. That increase belongs to new customers, not to the people who backed us when there was no reason to. Raising the price on the people who already said yes is short-term revenue bought with the only thing we actually need, which is being the vendor that does not do that.

We would rather have a thousand teams paying a small amount for a long time than fifty paying enough to resent us. That is a preference about the kind of company we want to run, and it is the reason the number is where it is.

Why this matters more now than it did

Commands are increasingly executed without a person driving each one. Coding agents, CI jobs and MCP servers act with the permissions of whoever set them up, and they act quickly and repeatedly. Standing access that was merely risky when a human held it becomes something else when it is handed to a process that never gets tired. The homepage covers what that looks like in practice; the pricing point is simply that the fix should not be gated behind an enterprise conversation.

We genuinely believe every team should have a system like this — ours or somebody else's. We have paid vendors considerably more for considerably less, and we set this price by asking what we would have signed off without hesitation when we were the ones doing the buying.