YouNeed.dev — home
Yavor ZagorskiSenior Full-Stack Developer
CV Let’s build
← All work

Shopify SaaS / Ecommerce Reliability / Monitoring

RevenueGuard

A Shopify application that checks whether a storefront’s purchase journey works, then turns confirmed failures into incidents with evidence.

TypeScript · React · Node.js / Express · PostgreSQL / Prisma · Playwright · Shopify APIs

Independent product / architecture & implementation

View Project ↗
RevenueGuard merchant dashboard showing paused monitoring and last-known storefront, cart and checkout results
Authentic development-store capture. Monitoring is paused; previous results are explicitly labeled as last known.
01

Project overview

RevenueGuard is an independent software product built around synthetic Shopify monitoring. Its merchant interface connects store setup, product protection, catalog changes, incident investigation, notifications and plan limits. The engineering work spans the application, integration layer and browser worker.

02

The problem

An available homepage does not prove that a shopper can select a variant, add it to a cart or reach checkout. Themes, applications and catalog changes can break individual steps while ordinary uptime checks continue to pass. The monitor therefore follows a purchase path and records exactly where verification stopped.

03

Engineering objectives & my role

I developed the application architecture, merchant-facing React interface, Shopify integration and monitoring workflow as an independent project. The core objectives were repeatable checks, useful evidence, bounded execution and incident signals that do not confuse a transient browser failure with a confirmed storefront problem.

04

System architecture

The React UI communicates with a TypeScript/Express API. PostgreSQL and Prisma persist workspaces, store connections, monitors, scheduled jobs, runs, step results and incidents. A separate Playwright worker performs browser checks, keeping execution and scheduling outside the web request lifecycle.

A shared database pause gate is read by the API, scheduler and worker. It lets maintenance stop future synthetic execution consistently without turning a paused system into an apparent storefront failure. Workspace checks protect merchant configuration and evidence access.

05

Monitoring engine & browser automation

The standard journey opens a product, selects a variant, adds one item, verifies the cart and attempts to reach a usable checkout. A fresh browser context limits state carried between runs. Product-specific monitors coexist with catalog rotation so coverage can extend beyond a single manually selected URL.

Theme differences require layered discovery and configurable selectors. Cart identity, quantity and currency are checked rather than inferred from an “added” message. Deeper checkout code can inspect contact, delivery and payment-page reachability; reaching that page is not evidence of payment completion.

06

Shopify integration & SaaS boundaries

OAuth handling validates the callback and binds installation state to the signed-in user and workspace. Shopify credentials stay server-side, with encrypted token storage. Catalog readers, verified webhook handling and installation lifecycle code support the store connection.

Subscription verification and entitlement policy are implemented separately from UI plan labels. Verified subscription data governs monitoring cadence, product limits, destinations and team access. This is implementation evidence, not a claim of paying customers or App Store approval.

07

Incident detection & evidence

Two compatible failures confirm an incident rather than alerting on the first unsuccessful run. A successful confirmation retry can classify an initial failure as transient. Recovery must match the relevant target and verification scope, so an unrelated successful product check cannot erase a different problem.

Persisted steps, screenshot evidence and diagnostic context explain the observed failure. Evidence retrieval is authenticated and workspace-scoped. Email, Slack and webhook notification code tracks delivery outcomes; an ambiguous interrupted send is distinguishable from a confirmed delivery.

08

Technical challenges & solutions

Store health is a statement about evidence freshness as well as the last result. The interface distinguishes paused, delayed, unverified and last-known states rather than presenting an old success as a current guarantee.

Browser failures also need classification: a theme-specific selector issue, a blocked execution environment and a reproducible cart failure call for different action. Structured diagnostics and confirmation runs preserve that distinction. Catalog changes provide context and verification targets; they are not automatically treated as the cause of an incident.

Current project status

Implemented independent application with a public project site. The repository contains monitoring, OAuth, catalog, incident evidence, scheduling, notifications and subscription-entitlement code. Screenshots document development-store behavior at capture time, not current service health or merchant adoption. Payment completion, automated revenue recovery, App Store approval and production scale are not claimed.

View Project ↗