A pattern in enterprise software has bothered me for years. A vendor charges a small team a modest per-seat price for the product, then charges that same team several times more per seat to add single sign-on. The same SSO that, on the vendor's side, costs almost nothing per seat once the integration exists. That price is not cost recovery. It is a gate on the controls a buyer needs to deploy the product safely, sold back to them as a premium.
When I decided what belonged in each tier of Atlas, this was the question I argued with myself about the longest. I put single sign-on, role-based access, and the audit log in the free tier. This post is the long version of why, and an honest account of what that choice costs the person making it.
The controls that should never be paywalled
Four controls decide whether a product is safe to deploy inside a competent organization. They are not the only controls that matter, but they are the four where a paywall does the most damage.
- Single sign-on. If a product cannot authenticate against the company's identity provider, every account is a separate password to rotate, every departure is a manual checklist, and every joiner is a help-desk ticket. SSO is how access follows employment instead of drifting away from it.
- Role-based access. A product where everyone is an admin is a product waiting for an incident. Named roles that map to what people actually do keep write access scoped and offboarding clean.
- An audit log. A product that records who did what, when, can be reviewed after something goes wrong. A product that does not, cannot. The cost of adding audit logging after the fact is large. The cost of writing it in from the start is small.
- Encryption in transit and at rest. Every managed platform gives you TLS for free and volume encryption on the storage layer by default. A vendor that meters either as a paid add-on is charging for a checkbox it did not have to build.
If any one of these sits behind an upgrade, the product is not safe to deploy on the lower tier. The paywall does not add security. It withholds it and calls the return of it a feature.
What it costs the vendor to give these away
None of this is free to build. Single sign-on is a real integration and a real surface to keep working as identity providers change their behavior. Role-based access has to be designed into the data layer early or retrofitted painfully later. An audit log is cheap if you write it from the first commit and expensive if you bolt it on after a year of features have assumed it is not there. So the controls cost engineering time, and I am not going to pretend otherwise.
What they do not cost is per-seat money. Once SSO works, the ten-thousandth login costs the vendor nothing the tenth did not. That is the tell. When a control has a high one-time build cost and a near-zero marginal cost, and a vendor still meters it by the seat, the price is not paying for the control. It is paying for the buyer's lack of alternatives.
Putting these in the base tier costs the vendor the thing the Enterprise SKU was quietly collecting: the tax on regulated buyers who cannot say no to SSO. Giving that up is the real cost of secure by default, and it is a revenue cost, not an engineering one. I decided I would rather not have that revenue than run a product whose safest configuration is the one I charge extra for.
Where SOC 2 fits, and where wrxstack sits
There is a second thing buyers ask for, and it is easy to confuse with this argument, so I want to separate them. Procurement teams ask for a SOC 2 report and treat it as the security gate. A SOC 2 report tells a buyer that a vendor wrote down its controls and an auditor checked they were followed for a stretch of time. That is worth something. It is also a different axis from the one this post is about. SOC 2 measures whether you do what you say. It does not measure whether the basic controls reach every customer or only the ones on the Enterprise plan. A vendor can hold a clean SOC 2 and still paywall SSO, and plenty do.
I should be plain about where wrxstack sits, because the argument only works if I am. wrxstack holds no certifications. No SOC 2, no ISO 27001, no third-party audit, no penetration test. If you are evaluating it for regulated data, the honest answer is to choose a vendor that has those things. What I am claiming is narrower and, I think, more useful: the controls wrxstack does ship, it ships to everyone. Single sign-on, role-based access, and the audit log are not behind a plan. The security page says the same thing, including every part where the answer is no.
The audit log is the control people underestimate
The audit log is the one I most wanted in the base tier, because it is the one that changes what a customer can do after something goes wrong. It records who did what and when: the account, the action, the target, the time. In Atlas it also records what the assistant did, because a product where an AI agent takes actions on a user's behalf needs the agent's actions in the same log as the human's, with the same fields. Without that, half of what happened in the account is invisible, and the half you cannot see is exactly the half you will want to reconstruct later.
Here is the honest scope. It is an activity log you can read inside the app. It is not streamed to an outside system, it is not cryptographically signed, and it is not held for years on my infrastructure. I am not going to describe it as more than it is. But what it is, everyone gets. The ability to answer who did what is not something a vendor should sell as an upgrade.
What "secure by default" does not mean
It does not mean shipping every control anyone could want. Atlas does not have customer-managed keys. It does not have SCIM provisioning, data-residency selection, or a single-tenant deployment, and it has no uptime SLA. Some of those are deliberate choices and some are just the reality of a product built by one person. The security page lists all of them under the heading of what wrxstack does not do. Baseline is not the same as complete, and I would rather be clear about the difference than blur it.
It also does not mean security is free for the customer. You still have to configure SSO, scope what the assistant is allowed to touch, and actually read the audit log when it matters. I tried to make those steps small. They are not zero.
The two things other vendors get wrong
Enterprise security as a SKU. The "Enterprise" tier exists mostly to gate the security features. Pricing shifts from per-seat to per-conversation or per-quote, and there is no meaningful product difference between the tiers other than the controls. This pattern lets a vendor collect a tax from regulated buyers in exchange for not shipping the controls to everyone. It reads as a pricing decision and lands as a safety decision.
Security as a checkbox. The vendor claims SSO, but the implementation only supports one identity provider. The audit log writes to a place the customer cannot read. The role model has exactly two levels, admin and everyone else. This pattern lets a vendor claim parity on the comparison grid without doing the work behind the claim. It survives a feature matrix and fails the first real deployment.
Both patterns are visible in a careful procurement review, and both fail the only test I actually trust: would I deploy this if my own job depended on it. I picked the defaults to pass that test, and I priced them so the answer does not change on the free tier.
The full and unflattering version of what wrxstack does and does not do is on the security page. If you want to argue about any of it, write to contact@wrxstack.com.