Scrutas · Forensic Web Audit Platform Case Study | ProductGurus
Internal Tool · In Production

Scrutas

Case study by Abhay Kumar · Updated July 2026

A forensic web audit platform, architected around a two-stage authorization model that earns trust before asking for access, then turns findings into a legally defensible, engineer-ready audit.

My role
Architecture → spec
Status
v1.0 · Live internally
Modules spec'd
23 across 4 domains
Target
Mid-market → enterprise
The problem

Four risk domains, no single tool covers all of them

Enterprise e-commerce and SaaS platforms carry measurable risk across four domains simultaneously: revenue suppression, regulatory exposure (GDPR, PIPEDA, Quebec Law 25), security vulnerabilities, and accessibility liability. Existing tools each cover a slice.

Tool categoryWhat it misses
Lighthouse / PageSpeedSecurity, compliance, legal exposure
SecurityHeaders.comScript inventory, consent, revenue impact
Detectify / ImmuniWebUX conversion impact, penalty quantification
Manual pen-test firmsPerformance, UX, SEO: cost-prohibitive for SME
Discovery

Two buyers, one authorization problem

EC

E-commerce / SaaS ops · Primary

CAD $50M–$500M GMV, in-house engineering, no dedicated security audit capacity. Needs findings in dollars and regulation, not just severity labels.

AG

Agencies & consultancies · Secondary

Deliver technical audits to clients; need a platform to underpin findings with defensible, structured data.

Backlog

User stories behind the architecture

US-01 As a site operator, I want to see real findings from my production site with zero commitment so I trust the audit before authorizing anything deeper. Must
US-02 As a site operator, I want to authorize deeper testing with a header, not credentials, so legal and security can sign off without friction. Must
US-03 As a site operator, I want findings quantified in dollars and regulatory exposure so I can prioritize remediation with leadership, not just engineers. Must
US-04 As an engineering lead, I want engineer-ready remediation directives, not generic advice, so my team can act on findings directly. Should
US-05 As an agency, I want white-label reports and API access so I can deliver Scrutas findings under my own brand. Should
US-06 As a customer, I want monthly re-audits with regression tracking so I know if new issues appeared since the last run. Could
Requirements

Spec'd as testable acceptance criteria

RequirementPriority
Stage 1 recon returns 3–5 high-impact findings in under 3 minutes, zero authenticationMust
Cryptographic domain-verification header (single-use, 72h, hash-only storage) gates Stage 2Must
Stage 2 completes the full 23-module audit within 15–45 minutes of verificationMust
Every finding carries severity, revenue impact, regulatory mapping, and a remediation directiveMust
Report export as interactive portal, PDF, Word, and JSON findings feedShould
Agency white-label tier with API access for integration into existing toolingShould
CI/CD-triggered audits on deployment for enterprise tierCould
My role

Resolving the authorization tension before writing a spec

Security audit products face a structural bind: customers need to see value before committing, but running a full audit without authorization creates legal exposure for both sides. I designed the two-stage model that resolves it, modeled on patterns operators already trust (Google Search Console, Let's Encrypt ACME), then specified the full module coverage, competitive positioning, and pricing anchor strategy end to end.

The architecture

Lead with unauthenticated value. Convert with verified depth.

Stage 1 · Open Reconnaissance

Zero commitment, immediate value

Runs on public HTTP responses only: headers, CSP, SSL, script inventory, WCAG contrast. Delivers 3–5 high-impact findings in under 3 minutes, no account required.

Stage 2 · Verified Forensic Audit

Authorized, legally defensible, complete

Gated behind a cryptographic domain-verification header. All 23 modules run: authenticated flows, storage analysis, credential scanning, subdomain enumeration.

Under the hood

A header, not a login, becomes the audit trail

The customer adds one HTTP response header; the platform polls for it every 60 seconds and logs the detection as a timestamped, immutable authorization record, attachable to any regulatory filing or client deliverable.

// Nginx
add_header X-Scrutas-Verify "scr_abc123_[token]";

// token properties
format: scr_[domain-hash]_[random-256-bit-hex] · validity: 72h · reuse: single-use
Pricing strategy

Anchor the price against the penalty, not the competitor

Every Stage 2 report states the maximum statutory penalty exposure identified. For pre-consent tracking under Quebec Law 25, that figure runs to $25M CAD per violation category. Against that, a $299 audit isn't a hard sell; it's the obvious next step.

Outcome

Live internally, running the full 23-module audit

Scrutas is built and running internally: the two-stage authorization model, all 23 audit modules, and the verification protocol are live. That two-stage model was the hard problem to solve: it's what turns a legally risky idea (auditing a site you don't own) into a defensible, authorized audit.

Roadmap

Five phases to platform

Phase 1–2

MVP: full audit engine + verification flow. Then agency white-label and findings API.

Phase 3–4

Monthly Monitor subscription + regression tracking. Then CI/CD integration and enterprise frameworks (HIPAA, SOC 2, PCI-DSS).

Phase 5

Third-party auditor marketplace: Scrutas becomes the infrastructure layer, not just the audit tool.

More case studies

See the rest of the work, or get in touch.