Skip to content
← Back to Systems

Access Control

Access designed for a real business.

Permissions must be easy to grant, limited by role, observable, and immediate to revoke.

Next.jsTypeScriptPostgreSQLMiddlewareRole-Based AccessSession Management

Why Access Became a Product Requirement

The application became business infrastructure, so authentication and authorization had to become part of the product architecture.

Once the application contained customer information, private notes, quotes, lead history, staff workflows, business analytics, and administrative controls, access could no longer be treated as a simple hidden route.

Layered Access Model

Multiple layers stand between a request and a sensitive action.

1

Identity Verification

Employee sign-in confirms who is requesting access before anything else happens.

2

Authorized Employee Allowlist

Only recognized employee accounts can reach protected areas of the application.

3

Secondary Unlock

A second verification step gates the most sensitive administrative actions.

4

Protected Admin Routes

Administrative routes are checked on the server, not hidden through the interface alone.

5

Role-Based Permissions

What an authenticated employee can do is scoped by role, not assumed from identity alone.

6

Environment-Aware Access

Access behavior is intentionally different across local development, staging, and production.

Role Boundaries

Three roles, three sets of operational authority.

Administrator

Can manage protected platform and employee controls.

Staff

Can access the operational tools required for daily work while remaining restricted from sensitive administrative actions.

Testing

Supports non-production or limited testing workflows without granting normal production authority.

Authentication Versus Authorization

Identity alone was not enough.

Authentication

Verifies who the person is.

Authorization

Determines what the verified person may do.

Session Revocation

Access must be immediate to remove.

The system is built around the operational need to invalidate sessions, disable employee access, remove permissions, support offboarding, respond to compromised access, and limit continued use after a role changes.

Throttling and Lockouts

Defensive behavior around repeated access attempts.

Repeated unlock attempts are subject to rate limits and temporary lockouts. Failed attempts are handled defensively rather than silently retried without limit.

Audit and History

A record of what happened, not just what is true right now.

Access eventsEmployee actionsPermission changesSecurity-relevant platform events

Platform Controls

Administrative controls beyond individual permissions.

Platform access switchesFeature or system kill switchesEnvironment controlsSync controlsMaintenance controls

Staging and Production Separation

Access and identity configuration must be intentionally separated across environments.

Distinct environment configurationTest usersProduction allowlistsDeployment-specific behaviorAvoiding accidental production access

Production Proof

What controlled access looks like in practice.

Sign-in page.
Secondary unlock page.
Staff access page.
Role controls.
Session revocation.
Access history.

Engineering Ownership

Built, deployed, and maintained end to end.

AuthenticationMiddlewareProtected routesServer-side checksRole modelingDatabase-backed employee recordsSession stateThrottlingAudit recordsTest coverageStaging and production configuration

Related Systems

Part of the connected commercial platform.

The goal was not merely to hide an admin page. It was to create controlled, role-aware operational access that could be granted confidently and revoked immediately.

View all systems →