Buy versus build got compressed

In the beginning there was SaaS.

SaaS was a mechanism to have code that was remote: you could manage cases, provide tickets, automate workflows. The buy-versus-build equation was defensible. Why would you build a CRM when Salesforce already existed? Why would you build a support desk when Zendesk already existed? The answer was almost always buy, because the software was stable and the switching cost of building it yourself was enormous.

Then GPT-3 arrived. A hundred million users. Everyone knows the story. But it was crude. You could ask it to scaffold a Next.js boilerplate and copy-paste the output somewhere else. It was not good for serious coding. It had no context, no memory, no access to your codebase.

Then came the CLI and the harness.

That was the lightning rod. A developer could give an agent — OpenAI, Anthropic, others — direct access to the codebase. Not copy-paste. Not a chat window. Real file access, real terminal commands, real iteration loops. The agent could read your code, understand your conventions, make changes, run tests, and fix what it broke.

That changed the buy-versus-build equation in a way SaaS never anticipated.

Buy versus build got compressed

When a senior engineer with a good AI harness can scaffold, test, and ship an internal tool in a day that used to take a team a quarter, the calculus changes for everything. Internal dashboards, admin panels, workflow engines, approval chains — things that used to justify a SaaS purchase because the build cost was too high.

But the compression is not infinite. It applies to the first version. The boring, useful, messy middle of maintaining, securing, operating, and evolving software over time still costs real engineering attention. The harness makes it faster to build the first pass. It does not make it cheaper to own the tenth iteration.

That matters here because AfterAuth lives in exactly that gap.

The founding obsession

I will be honest about where this started.

I was obsessed with receipts. Not financial receipts — decision receipts. A cryptographically verifiable record of what was requested, what signals existed, what policy matched, and what outcome was granted. Tamper-proof. Auditable. Something a bot could not intercept or replay without detection.

I built that and called it PolicyGate. I thought I had created a new open policy agent. Then I discovered that OPA — Open Policy Agent — already existed and had been solving policy evaluation for years.

That was a useful embarrassment. It forced me to find the actual wedge instead of the generic one.

The wedge that is underserved

There are great authorization providers: Clerk, Okta, Auth0, and others. They solve identity. They answer who this user is.

What they do not solve — and it is not really what they are trying to do — is what happens after auth. The mechanism for building trust with a user before you have a credit card from them. The runtime decision about how much costly value an authenticated but unproven account should receive right now.

I call that the after-auth control plane.

You could say: why not build this myself?

Most teams should try. When you have a handful of users and simple economics, a feature flag and a database column will work. You do not need a product for that.

It stops working when the problem gets messy. When you gate a wave of users who would have converted into paid customers if they had seen value first. When it goes the other direction and you let in a flood of free accounts that burn compute, and you get a surprise AWS bill that nobody can explain. When support asks why one user got blocked and another got unlimited access, and the answer is scattered across six systems.

That is when most teams realize they should not have hand-rolled this. They should use something purpose-built for the after-auth trust decision.

What I am actually building

I do not need to bore you with a feature list. But the shape matters, because it explains what kind of product this is.

Trust signals from your auth provider. Clerk, Okta, Auth0, and others already know things about the user: email domain, account age, verification status, invite context. AfterAuth turns those signals into inputs for the trust decision without replacing your auth stack.

Policy controls for non-developers. Business ops, rev ops, and growth people should not need to file a pull request to change who gets what. A friendly UI for creating and tuning policies, with version history and audit trails.

Developer-first SDK. A clean integration path for Next.js and other frameworks so the developer experience is not a tax. Call evaluate, read the outcome, move on.

Safeguards for vibe-coded integrations. If someone is building fast with an AI harness and wires AfterAuth in, the defaults should be safe. A bad integration should not brick access for real users.

Human-in-the-loop approval. Easy mechanisms to require review for high-risk decisions, ambiguous signals, or high-cost actions. Not every trust decision should be fully automated on day one.

The analogy

Think of it like GitHub for the trust layer after login.

GitHub does not write your code. It gives you a structured workflow for reviewing, approving, and shipping changes with an audit trail. AfterAuth does not make your product decisions for you. It gives you a structured workflow for evaluating, granting, limiting, and explaining trust decisions with a receipt.

The users you are protecting against are not always bad actors. Some are bots. Some are free-tier arbitrageurs. Some are just new accounts that have not proven anything yet. And some are your best future customers who need a path to value before they are ready to hand over a credit card.

You can allow them to use your product before the full value proposition is proven. You can build trust with them over time. You can explain every decision later.

That is the thesis. If you are running a PLG company where activation has real marginal cost, I would like to hear about your specific use case.