SORCH

internal

An internal SERP operations system built around review, queued processing and safe export.

My role
Workflow design, product requirements, review gates and verification.
Last reviewed

Problem

Repeated SERP collection needs cost visibility, predictable queue behaviour, recoverable progress and exports that do not create spreadsheet formula risks.

My contribution

  • Review-before-queue workflow and request estimation
  • Result grouping, persistence and formula-safe export requirements
  • Test, type-check, build and controlled smoke verification

Constraints

  • Each live provider request has a cost and must not be repeated casually.
  • The application is authenticated and internal, not a public self-service product.
  • Credentials, provider details, workflow identifiers and private data cannot appear in a public case.

What I worked on

  1. Put request counts and review before queue submission.
  2. Structured queued processing, shared progress, top-20 grouping and worker-health visibility.
  3. Required safe CSV export and verified the production build path.

Verification

Application tests

47 tests passed on 22 July 2026.

Static checks

TypeScript and the Next.js production build passed on 22 July 2026.

Controlled smoke run

One previously recorded paid request completed end to end; the internal run identifier is not public copy.

Present state

SORCH is a tested internal operations surface with explicit review, queue, progress and export controls.

Limits

  • It is not a public self-service product.
  • This case does not claim broad adoption, commercial outcomes or management scope.
  • Private credentials, endpoints and run identifiers remain undisclosed.

Further evidence