A platform engineered to be reviewed.

Every customer-data table in Strkr carries a tenant_id column. Every query the API runs is scoped to the authenticated session's tenant before it leaves the handler. Cross-tenant reads are not a policy decision or a code-review item. They are architecturally impossible, because the query layer refuses to compile a statement that is missing the scope.

This matters because the alternative is the pattern that most multi-tenant SaaS still uses: shared tables with permissions enforced at the controller. One missed middleware, one developer who copies a snippet from a public gist, and a bug becomes a breach. Strkr pushes the enforcement down to the data layer so the controller cannot forget.

Tenant scoping extends through audit logs, exports, backups, and search indexes. A workspace that gets deleted is gone from every surface, not quarantined behind a cron job that someone forgot to run.

Strkr ships with a core data model that mirrors the real work of a revenue team. Accounts. Contacts. Deals. Opportunities. Activities. Tasks. Products. Line items. The relationships between those objects are enforced in the schema, not papered over in the UI, which means reporting against the model is reliable and imports do not quietly break foreign keys.

Alongside the core objects, every workspace can define custom objects. A property management firm can model buildings, units, and leases as first-class records. A consulting firm can model engagements, phases, and deliverables. Custom objects get the same treatment as core objects: audit logs, API coverage, permission scoping, import and export, and reporting.

On top of the record model sits a field-level permission system. Any field, on any object, can be hidden, read-only, or writeable per role and per team. The permission layer is enforced on the server, not just in the UI, so a user who inspects the API response cannot see a field that policy hid from them in the layout.

Every piece of Strkr infrastructure is defined in TypeScript using Pulumi. The route tables, the Lambda functions, the RDS parameter groups, the CloudFront behaviors, the IAM policies, and the secrets wiring all live in version control. No one logs into the AWS console to make a production change. Every deploy is a pull request, reviewed, and traceable.

Deploys run from CI on green builds. The pipeline builds the application once, deploys to the dev environment, runs an automated smoke test, and then promotes the same artifact to production. The dev-before-prod pattern is enforced in the pipeline, not in a checklist. Every production release went through dev first, every time, with no exceptions for "small" changes.

Releases are reversible. The API route registration is append-only, which means an older client never finds a route it used to call missing from the current build. Database migrations run forward only, with the schema designed so that the previous API version is still valid against the next schema. The result is zero-downtime rolling deploys that most customers never notice happened.

Every API request on Strkr starts with a correlation ID that follows the request through every Lambda invocation, every database query, every outbound call to a third-party integration, and every log line that the handler emits. When support needs to debug a problem, the correlation ID is one search away from the full trace.

CloudWatch collects metrics on every Lambda. The dashboards expose request rate, latency percentiles, error rate, and cold-start count per endpoint. Alarms fire on p99 latency and on 5xx error rate, routed to on-call before customers notice. The team's goal is boring dashboards.

Structured logs make the correlation ID searchable, which means tracing a request from the API Gateway through to the database query and the webhook delivery takes minutes, not an afternoon. The audit log, exposed to every workspace owner, is a separate surface built for the customer's incident response, not an operational log that happens to be visible.