The parts AI can't do alone

The part nobody writes about

Technical sprint retrospectives focus on the interesting engineering: the AI integration, the framework choices, the performance optimizations. Nobody writes about the three days spent getting Stripe webhooks to reliably update subscription state, or the afternoon debugging why Clerk user creation events were arriving out of order and corrupting the onboarding flow, or the evening designing a credit system that was both economically sound and comprehensible to a first-time user.

This is that piece. The business layer: authentication, authorization, billing, credits, team management, and role-based access control. The unsexy infrastructure that separates a demo from a product.

The business layer took roughly 25% of the 100 hours. It does not produce visible features. It produces the invisible foundation that makes every visible feature trustworthy. Without it, you have a prototype. With it, you have something people can pay for.

• 6 Plan Tiers: Free, Individual, Lead, Leader, Org, Enterprise, each with distinct credit and feature logic
• 6 RBAC Roles: Owner, Admin, Manager, Member, Scorer, Viewer
• 30 Permissions: Discrete permission checks across every sensitive action
• 14 Day Trial: Reverse trial: full Leader access, then gate. Not a feature-limited free tier.

The pricing architecture

The pricing model went through several revisions before settling on the current six-tier structure. Early versions had fewer tiers, but the expansion motion needed more granularity to serve the full buyer spectrum from individual contributors to enterprise teams.

Six tiers: Free ($0, permanent with credit limits), Individual ($49/mo, full individual access), Lead ($149/mo, coaching layer), Leader ($299/mo, full intelligence and coaching), Org ($599/mo, multi-seat with diagnostics), Enterprise ($2,500+/mo, custom deployment, SSO, priority support). Each tier has a clear buyer archetype, a clear expansion trigger, and a clear revenue rationale.

The credit system maps to the economic reality of AI scoring. Every full product score consumes Claude API tokens at a cost that scales with response quality. Free users get enough credits to score their product once and understand the value. Individual and Lead users get enough for ongoing quarterly scoring. Org accounts get a shared credit pool that scales with seat count. The model is honest about costs while remaining accessible at the entry level.

The reverse trial

The 14-day trial is not a feature-limited free trial. It is a reverse trial: new users get full Leader access for 14 days, then the product gates to Free tier limits unless they subscribe. This design choice was deliberate and the reasoning is worth documenting.

Feature-limited free trials hide the product. You sign up, you see a watered-down version of the thing, and you have to mentally model what the full experience would be like. The buying decision requires imagination, not experience. Reverse trials show the real product first. You sign up, you score your product with full AI analysis across all 27 dimensions, you get the complete coaching experience. Then, when the gate arrives, you are not deciding whether to buy something unfamiliar. You are deciding whether to keep something you have already used and found valuable.

The conversion psychology is different. The reverse trial creates loss aversion rather than aspiration. "I will lose access to this thing I have been using" is a stronger motivator than "I might gain access to something I have not tried." Twenty years of conversion rate data from B2B SaaS products consistently supports this pattern for tools that deliver fast initial value.

Clerk and the authentication boundary

Clerk handles authentication and session management. The decision to use Clerk rather than building auth from scratch or using a lighter library like NextAuth was about surface area. Authentication is not a differentiator. It is a liability. Every custom auth implementation carries risk: token handling, session expiry, MFA, SSO, webhook reliability. Clerk owns that surface. Dacard does not need to.

The critical architectural decision was where to draw the boundary between Clerk and the rest of the application. The rule: Clerk stays in the web application layer. The core package never imports from Clerk. Business logic functions accept a userId or accountId as a parameter. This means the scoring engine, the integration adapters, and the database layer can be tested without mocking authentication. It also means that if Clerk is ever replaced, the blast radius is limited to the web layer.

Clerk webhooks trigger database synchronization: when a user is created in Clerk, the webhook creates the corresponding user record in Turso and initializes their credit balance. When an organization is created, the webhook creates the account record and assigns the creator as Owner. When a user joins an organization, the webhook assigns the default Member role. This synchronization is non-trivial and requires careful handling of out-of-order delivery, idempotency, and partial failure states.

1. User signs up via Clerk: Clerk handles credential validation, email verification, OAuth flows
2. Clerk fires user.created webhook: Web API route receives event, verifies signature, queues DB sync
3. Turso user record initialized: User row created with clerkId foreign key, plan set to Free, credit balance initialized
4. Onboarding flow begins: 4-step wizard: role selection, company details, product description, score trigger
5. First score consumes credits: Credit check enforced at API route level, deduction logged with jobId for auditability
6. Stripe subscription event updates plan: Webhook updates plan tier, resets credit balance, unlocks gated features

RBAC at the permission level

Role-based access control is one of those features that looks simple in a requirements document and reveals its full complexity only when you build it. Six roles sounds manageable. Thirty permissions sounds like a spreadsheet. The difficulty is in the edge cases: what happens when an Owner downgrades their account and there are Admins with permissions the new tier does not support? What happens when a Member tries to score on behalf of an Org account that has exhausted its credit pool? What happens when someone's role is changed while they have an active session?

The six roles form a clear hierarchy. Owner has all permissions and cannot be demoted by anyone but another Owner. Admin can manage users and settings but cannot delete the account. Manager can run diagnostics and manage integrations but cannot change billing. Member can view scores and submit self-evaluations. Scorer is a limited role for external contributors. Viewer is read-only.

The 30 permissions are checked at the API route level, not in the UI. UI gating is for experience quality. API gating is for security. These are not the same thing and should not be implemented the same way. A user who finds a hidden button through inspect element should hit an authorization error at the API boundary, not an error because the UI component was not rendered.

The PLG tension

There is a genuine tension in building the business layer for a product-led growth motion. PLG products succeed by being frictionless for the individual contributor who discovers them. They scale into organizations by having enough infrastructure to satisfy procurement, security, and IT requirements when an enterprise buyer shows up.

These two objectives pull in opposite directions. Frictionless onboarding means fewer fields, fewer gates, faster time to value. Enterprise readiness means SSO, audit logs, RBAC, custom data residency, SOC 2 documentation. Every gate you add to serve enterprise buyers is friction that reduces IC activation. Every friction you remove to serve ICs is a gap that an enterprise security review will flag.

The decision was to build the enterprise infrastructure invisibly. The RBAC system, the credit audit log, the Clerk organization model, the Stripe subscription lifecycle: all of it is enterprise-grade, but none of it surfaces to a free-tier user who just wants to score their product. The IC experience is simple by design. The enterprise capability is there when the deal requires it.

IC / Free Experience: What an individual sees

• Sign up, verify email, answer 4 questions
• Get scored across 27 dimensions
• See coaching recommendations
• Upgrade when credits run low
• No roles, no RBAC, no billing complexity

Enterprise Reality: What the infrastructure supports

• SSO via Clerk Organizations, custom domain support
• 6-role RBAC with 30 discrete permission checks
• Full credit audit log with jobId traceability
• Stripe subscription lifecycle with webhook reliability
• Org-level data isolation, no cross-account leakage

Why this work matters

The business layer does not show up in product screenshots. It does not get mentioned in feature announcements. The users who benefit from it most are the ones who never noticed it working correctly.

But it is the difference between a product and a business. Features generate signups. Business infrastructure generates revenue, retention, and trust. You can build a compelling demo without it. You cannot build a company.

The 25 hours spent on authentication flows, billing webhooks, role hierarchies, and credit accounting produced zero visible UI. They produced something more valuable: a product that a serious enterprise buyer can look at and decide to trust. That trust is the foundation every subsequent feature builds on.

> The business layer is not unsexy. It is the most consequential work in any commercial product. The features that users love are built on top of it. Without it, the features are a demo. With it, they are a product.